これの事ね＞＜ -- 「マイクロソフトを嫌っていたのではない、われわれが嫌われていたのだ」――Rubyまつもとゆきひろ氏が語る、MSの壁 - ITmedia NEWS http://www.itmedia.co.jp/news/spv/1606/08/news138.html
ていうかそういう意味でも、最初の方に例として出したRubyの(の実装の)UNIX依存問題って典型例かも＞＜ 依存しないものを作りたいのかそうじゃないのかさっぱりわからない＞＜ Matzは「WindowsがUNIXでは無いのが悪い」としかとれない事を言ってたけど＞＜
(じゃあマルチプラットフォームじゃなくてUNIX依存環境なんじゃんって＞＜)
おささんがマストドンに依存させたくないピラミッドを描いてるのはわかる＞＜(ファイルの許容範囲のやり取りはマストドンに限った話では無いので汎用的な仕様になるべきでしょ？＞＜(でもそれをhttpにというのはおかしいし、実際歴史的な色々で難しいんでしょ？＞＜))
orange
さんがブースト
多分、二人が思い描いている図のピラミッドが違う。
より抽象化されるのは上の層であって下の層に降りる(依存する)事ではない＞＜
「マストドンのクライアントはメガドラの素晴らしいアーキテクチャに依存したメガドラ専用の物にすればいいと思うし全ての計算機はメガドラになるべき」みたいなめちゃくちゃな提案してない？＞＜っていってる＞＜
orange
さんがブースト
ああ、メガドラしか考えてない仕様っていうのは、マストドンのアップロードが許容範囲を超えて可能なこと？それは、メガドラで動くゲームすら動いてない状況だと思うけど。
それは突き詰めると全ての計算機のアーキテクチャは統一されるべきという話じゃないの？＞＜
より抽象化されるべきとは逆だよね？＞＜
雑に言うとRubyとかJavaとか .NETなんてものは使わず、もっと下の層、究極にはハードウェアが直接仕様を持ちそこに依存すべきだって話になるよね？＞＜
orange
さんがブースト
指示語の対応が分からんけど、メガドラしか考えてない仕様っていうのは、アップロードサイズが取れない話？jsでやれって話？
むしろ、オレンジ氏の言う「マストドンがAPIでアップロード許可サイズを返せ」って言う話はメガドラしか考えてない仕様で、わたしの言う「httpレベルで解決しろよ」って話はコンピュータとして統一しろって話だと思っていたけど。
それでいうところの例えばメガドラしか考えてない仕様ってどうなの？＞＜って話をさっきから・・・＞＜
orange
さんがブースト
個人的には、Windowsとか、x86とか、PC9801派とX68000派とか、メガドライブ派とかプレステ派とか、そういうレイヤーも取っ払って「コンピューター」という一種類になれば良いと思っています。
実装の依存は、まぁ・・・うんって議論の余地はとても大きいかもだけど、仕様での依存はとてもマズいかも＞＜(発想がむしろ使い捨て的かも＞＜)
よくわかんないけど、「下の層に依存して解決出来ちゃうなら依存しちゃおう どうせその上で使う人ばかりでしょ」だと、例えばWindowsでしか動かないとかx86でしか動かないとかって話と変わらないし、プラットフォーム非依存の環境をも否定する事になるかも・・・＞＜
この「別のレイヤに依存させるべきではない」の部分、Rubyのプロセス管理がUNIX依存で酷いという話にも微妙に似てる気がしなくもない＞＜
マストドンの鯖が、受け入れられるファイルの仕様(設定)をしゃべるべきでは？＞＜ って話になんでhttpレベルの話が出てくるの？＞＜
ウェブの話ならそうだろうけど、Androidのマストドンクライアントアプリの話だよねこれ？＞＜；
よくわかんないけど、全くスマートではなく単なるバッドノウハウの塊にしか見えないかも＞＜
orange
さんがブースト
アップロードできないサイズのファイルがアップロードできてしまうの、jsで今からアップロードしようとしているファイルのサイズを取ってエラーにすればできるはず。httpサーバ側で先にcontent-lengthを取得して確認できたら良いんだけど、これはファイルが実際に届いてリクエストが完了してからじゃないと無理だっけ。届いた時点でメモリに入りきらないファイルということでエラー扱いになっちゃうし。jsでチェックするのがスマートか。
LCXじゃなくても、無線LANってアンテナケーブルで直結して使えないのかな？＞＜
マストドンがかなり独特な構造してるって話を書こうと思ったけど、こっちの話題が片付いてから(？)にしよう・・・＞＜
- ＠orange_in_space
2017年 4月に登録
