[JDEV] File transfer and Jabber

[mark at mjwilcox.com]

I think this plan sounds better. One improvement I would add is 
that instead of requiring file-upload, make WebDAV an option as 
well.

mark
On 23 Apr 01, at 9:14, Iain Shigeoka wrote:

> At 06:46 PM 4/22/2001 -0700, Jens Alfke wrote:
> 
> >>Since we already have the whole connection system in jabber I was
> >>thinking of when I want to transfer a file, I'll send it to the
> >>server that I am connected to and send the file as chunks (size and
> >>rate depending on flowcontrol parameters).
> >
> >In-band file transfer seems to be a somewhat controversial topic. I
> >brought it up a few weeks ago and several people objected to sending
> >all that data through the server. It is, however, by far the most
> >straightforward solution to firewall and NAT issues.
> 
> I think its perfectly "legit" for client developers to approach this
> problem this way.  However,  I think in terms of scaling Jabber up as
> an overall system, this would severely limit the size of a practical
> Jabber user community.  The traffic through a Jabber server would just
> be too high if file sharing became widespread and took this approach.
> 
> I believe that if Jabber client developers want to see Jabber grow to
> the popularity of a system like AIM we need to consider what a Jabber
> system with 1 million users would look like and how to make that
> practical.  In-band file transfers are just not feasible using this
> approach. Oob file transfers must be the solution.  This allows the
> heavy bandwidth usage to be distributed and shared.  Either direct
> client-to-client or client-server-client where the server can be
> switched to some other system.
> 
> How about this for a proposal.  Define specifications for a separate
> oob server.  To make it simple to convert any web server into a
> compliant oob server, we define the system using only httpd.  It
> accepts file uploads given authentication, and allows file downloads
> using temporary URL links.  Part of the standard should be incentives
> to run oob servers by people other than Jabber.  For example, perhaps
> the standard defines that clients must download from the oob server an
> URL, an image file (one of say three types defining three standard ad
> size types), and the requested URL.
> 
> Clients transferring files out do the following:
> ----------------------------------
> Client hits oob server with a standard HTML form submitted and filled
> out with standardized authentication information.
> 
> Server responds with a standard HTML page either defining login
> success or failure. Authenticated clients use http file upload to
> upload the file.
> 
> Server responds with a page with the temporary URL the file obtain be
> obtained, a one time key to access the file, and a timeout value
> specifying the amount of time the URL will be valid.
> 
> Client uses Jabber to send a message to client transferring file in
> with the URL, one time key, and timeout value.
> 
> 
> Clients transferring files in do the following
> ----------------------------------
> Client receives jabber message with file URL, one time key, and
> timeout. Client hits the oob server at the URL given, specifying the
> one time key as a cookie.  It must actually perform three downloads to
> be compliant:
> 
>          URL - Contains the ad html link, FILE_URL, and ad image
>          options or 
> html indicating no ad required
> 
>          AD_URL/ad_size.png or ad_size.svg - Contains the Ad image. 
>          The 
> entire and exact URL was specified in the ad image options list.
> 
>          FILE_URL/file.x - A direct link to the desired file (also
>          obtained 
> from the original URL)
> 
> The client is then required to display the ad and link it to the ad
> HTML.  The commercial aspect (ads) is there to encourage third parties
> to host oob servers.  People generous enough to donate free oob
> servers will of course have the option of not turning on ads.  The
> client transferring information out is the one that has created an
> account with a given oob server (and agreed to whatever ad system they
> run).  The client getting files doesn't need to have any oob server
> accounts to participate.  If you want to encourage file sharing, then
> you could reverse that so that the client getting files must have the
> oob server account, and that initial login is reversed (the
> downloading client logs in, gets the one time key, the uploading
> client uses the key as a cookie to perform the upload, then the
> downloading client uses the key and the url info to get the file).
> 
> I think its easier to envision some system like this scaling and being
> more practical from a "who's going to pay for the bandwidth" point of
> view.
> 
> Comments?
> 
> -iain
> 
> 
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev
> 
> 


Mark Wilcox
mark at mjwilcox.com
Got LDAP?