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
さんがブースト
選択TLみたいなのはほしいな。
orange
さんがブースト
マストドンはそろそろ連合TLじゃなくて人工知能を利用した”興味がありそうなアカウントだけをピックアップしたTL”を作るタイミングに来てると思う
一方で、リサイズしないとアップロードできないのに、そのアップロードできないファイルを受け入れて、リサイズもされなくてアップロードに失敗するのはバグというか正しく無いデザインと言えると思うし、リサイズ機能は内蔵されるべきであろうし、欠陥かも＞＜
(アプリの欠陥かマストドンの欠陥かはわかんないけど＞＜(例えば許容されるサイズを返すAPIがあるのであれば、アプリの欠陥かも＞＜))
- ＠orange_in_space
2017年 4月に登録
