Notez que ça a déjà commencé : à une époque on avait FTP, puis SFTP comme protocole standard et indépendant du service pour les transferts de fichiers, aujourd'hui la mode est aux clouds à API spécifique.
SFTP, FTPS, pNFS, AFS, gsiFTP, SMB & so on sont POSIX-like donc supportent les random I/O ( particulièrement le random write ) et par conséquent ne sont pas adapté aux cloud storages qui sont généralement conçus pour du write-once / read many pour des raisons de scalabilités ( cf NRW, R >> W ).
Le principal interet de HTTP, outre le coté Web et le passage outre des problèmes de pare-feu, est le coté atomic de l'operation "PUT" qui match parfaitement le "write-once".
Mais je t'accorde que ça ne justifie absoluement pas la diversité en terme d'API : S3, Swift, Azure, WebDav, Google Drive, Rackspace, etc…
[^] # Re: Pas au courant
Posté par Firwen (site web personnel) . En réponse au journal *Dav: Google fait marche arrière. Évalué à 4. Dernière modification le 06 juin 2013 à 22:02.
SFTP, FTPS, pNFS, AFS, gsiFTP, SMB & so on sont POSIX-like donc supportent les random I/O ( particulièrement le random write ) et par conséquent ne sont pas adapté aux cloud storages qui sont généralement conçus pour du write-once / read many pour des raisons de scalabilités ( cf NRW, R >> W ).
Le principal interet de HTTP, outre le coté Web et le passage outre des problèmes de pare-feu, est le coté atomic de l'operation "PUT" qui match parfaitement le "write-once".
Mais je t'accorde que ça ne justifie absoluement pas la diversité en terme d'API : S3, Swift, Azure, WebDav, Google Drive, Rackspace, etc…