アカウント名:
パスワード:
と思ったら、ChromeはFTPS未実装だったのね・・・。ならHTTPS一択ですわ。
そろそろFTPはobsoleteかそれに近い準ずる扱いにするRFCをIETFが出すべき時期だと思う
FTPのダメなところ
*文字コード地獄。両方asciiなら別に問題ないが、今時そんなわけない。
*mimeタイプを知らない。テキストとバイナリ以外の区別に興味がない。
*lsが環境依存。ファイルリストを要求すると、lsやdirの出力をそのまま送って来るが、セマンティックなにそれななテキストだから、GUIのためのパーサを書くには全世界のlsの書式を網羅しないといけない。そんなの無理というか、ブラウザなんかに積みたくない。
*エラー処理が……
> テキストとバイナリ以外の区別に興味がない
これを利点だと思ってる老害が通りますよっと
#わりと本気なのでAC
俺も老害だと思うが、バイナリ以外使いみちないだろ?テキスト使うとか、有りえん
電話回線時代ですが、FTPでよかった点はFTPのサーバー間転送機能ですね。今は、データ接続で大抵どっちかに制限がついてるから、サーバーの組み合わせでできないこと多いし。(データ接続受け付けるIPか、データ接続先IPか(コントロール接続と同一IPのみの)制限付いてる)
ブラウザでダウンロードするだけならFTPいらないですね。
WebDAVプロトコルって、現状だと枯れているもんでしょうか。。
subversionやCalDAVで使うくらいには枯れてるかと。gitはwebdavだとダメダメらしいが、何が問題かは知らん。何となくgitの問題な気はするが。
Windowsは確かxp辺りからWebClientってサービスが既定で有効になってエクスプローラーでWebDAVアクセスできたような。でも8.1か10で既定で無効になったもするけれど。
cgiとかじゃないから、リポジトリのファイル構造をそのまま提供するから必要最小限の通信が出来ず遅い&更新をトリガーとした処理も起動できない、のが問題らしい。
でもこれ、SubversionでもHTTP/WebDAVアクセスだと遅いらしいからgit固有の問題ではなさげ。トリガーを仕込めるかもサーバに使うソフトウェア毎の個別対応になりそうだし、任意のトリガー仕込めるような柔軟なサーバを考えるなら専用プロトコル吐いたほうが良さそう…
必要最小限の通信についてはファイル構造次第で多少は改善できるだろうけど、一定以上の効率改善はサーバ側のストレージ容量との非効率なトレードオフしかできんだろうな…クライアント側の状態に正確に対応したファイルを一々サーバ内で配置するのは色々面倒くさそう。サーバ内でシンボリックリンクないしハードリンクを山ほど作るってのはありなんだろうか?
確かに想像すると凄く遅くなりそう。diffを送れば済むんだけど、だったらputじゃなくてpostでいいよね、って話じゃない?差分の取れないバイナリだけputするんならアリ。ただ、その場合も更新情報を一か所にまとめて集中管理しないと、タイムスタンプの取得だけでheadで問い合わせるならかなり無駄だね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
最初のバージョンは常に打ち捨てられる。
そこはFTPSへの移行を推奨する所じゃないのかよ? (スコア:0)
と思ったら、ChromeはFTPS未実装だったのね・・・。
ならHTTPS一択ですわ。
Re:そこはFTPSへの移行を推奨する所じゃないのかよ? (スコア:0)
そろそろFTPはobsoleteかそれに近い準ずる扱いにするRFCをIETFが出すべき時期だと思う
Re:そこはFTPSへの移行を推奨する所じゃないのかよ? (スコア:2, 参考になる)
FTPのダメなところ
*文字コード地獄。両方asciiなら別に問題ないが、今時そんなわけない。
*mimeタイプを知らない。テキストとバイナリ以外の区別に興味がない。
*lsが環境依存。ファイルリストを要求すると、lsやdirの出力をそのまま送って来るが、セマンティックなにそれななテキストだから、GUIのためのパーサを書くには全世界のlsの書式を網羅しないといけない。そんなの無理というか、ブラウザなんかに積みたくない。
*エラー処理が……
Re: (スコア:0)
> テキストとバイナリ以外の区別に興味がない
これを利点だと思ってる老害が通りますよっと
#わりと本気なのでAC
Re: (スコア:0)
> テキストとバイナリ以外の区別に興味がない
これを利点だと思ってる老害が通りますよっと
#わりと本気なのでAC
俺も老害だと思うが、バイナリ以外使いみちないだろ?
テキスト使うとか、有りえん
Re: (スコア:0)
電話回線時代ですが、FTPでよかった点はFTPのサーバー間転送機能ですね。
今は、データ接続で大抵どっちかに制限がついてるから、サーバーの組み合わせでできないこと多いし。
(データ接続受け付けるIPか、データ接続先IPか(コントロール接続と同一IPのみの)制限付いてる)
ブラウザでダウンロードするだけならFTPいらないですね。
Re: (スコア:0)
WebDAVプロトコルって、現状だと枯れているもんでしょうか。。
Re: (スコア:0)
subversionやCalDAVで使うくらいには枯れてるかと。
gitはwebdavだとダメダメらしいが、何が問題かは知らん。何となくgitの問題な気はするが。
Windowsは確かxp辺りからWebClientってサービスが既定で有効になってエクスプローラーでWebDAVアクセスできたような。
でも8.1か10で既定で無効になったもするけれど。
Re: (スコア:0)
cgiとかじゃないから、リポジトリのファイル構造をそのまま提供するから必要最小限の通信が出来ず遅い&更新をトリガーとした処理も起動できない、のが問題らしい。
でもこれ、SubversionでもHTTP/WebDAVアクセスだと遅いらしいからgit固有の問題ではなさげ。
トリガーを仕込めるかもサーバに使うソフトウェア毎の個別対応になりそうだし、
任意のトリガー仕込めるような柔軟なサーバを考えるなら専用プロトコル吐いたほうが良さそう…
必要最小限の通信についてはファイル構造次第で多少は改善できるだろうけど、
一定以上の効率改善はサーバ側のストレージ容量との非効率なトレードオフしかできんだろうな…
クライアント側の状態に正確に対応したファイルを一々サーバ内で配置するのは色々面倒くさそう。
サーバ内でシンボリックリンクないしハードリンクを山ほど作るってのはありなんだろうか?
Re: (スコア:0)
確かに想像すると凄く遅くなりそう。diffを送れば済むんだけど、だったらputじゃなくてpostでいいよね、って話じゃない?差分の取れないバイナリだけputするんならアリ。ただ、その場合も更新情報を一か所にまとめて集中管理しないと、タイムスタンプの取得だけでheadで問い合わせるならかなり無駄だね。