[JDEV] File Transfer Proposals

Julian Missig julian at jabber.org
Sat Feb 16 16:39:02 CST 2002


PASS wouldn't be permanently storing mp3 and divx files and whatever
else people send, it's just a proxy.

I want to get OOB and PASS working with decent JEPs before we even begin
arguing webdav & friends, because that has a lot of the filesharing and
caching issues...

As for using your own protocol, I'm not a fan of that at all. There is
really no reason to recreate HTTP/FTP and other such file-sending
protocols. The entire point of sending files out-of-bound is that there
are existing protocols which already do it and do it better, because
they have experience.

In the end, using HTTP/FTP instead of writing our own protocol probably
involves *less* work because there is craploads of code out there to
copy, and HTTP/FTP don't have any of the bugs we may be creating when we
create our own protocol.

So, again I ask for comments which tell me *what is wrong with HTTP/FTP
OOB and PASS*, not comments which tell me how you want to do it.

Julian

On Fri, 2002-02-15 at 22:02, aliban at gmx.net wrote:
> hello again,
> it might sound annoying but as i already mentioned i´m currently 
> working on a filesharing component, already done parts of it, will be 
> done next week(maybe).
> 
> My idea behind filetransfer was not to send the file over jabber 
> server because this would flood the server soon with mp3 and divx 
> movies (esspecially filesharing). Whatever we have a xml 
> connection and that would be ideal to control the filetransfer, you 
> can send "abort", "resume" commands via jabber xml and do the 
> byte transfer with another very primitive socket that simple creates 
> a connection and pushs the data through it. In my point of view this 
> has two advantages. writing tcp sockets does not need much time 
> (in comparition with writing a http/ftp server). a simple tcp socket is 
> easier to control then many spawned http servers. consider, that 
> each http thread/http account would have to need it´s own 
> restrictions.
> of course a http has the advantage that you can browse the 
> directories and find other interesting files but what if user does not 
> want to allow this? (i.e. he wants to offer this person only one file) I 
> wrote a iq for my jabberfs to enable filebrowsing as well as updating 
> the jabberfs databases...
> http://skabber.rudbek.com/jabberfs/jabberfs-iq-files.txt
> there you have two ways to find out what kind of files are offered at 
> this client. a) you ask for a full file list of all subdirs (it is optimised, 
> it wont send everything again each time but only the changes)
>  b) you browse the file step by step by geting only the files of the 
> *current* directory. for the protocol for jabberfs is only onw iq not 
> finished yet, the jabberfs:iq:options to set the connection speed as 
> well as some other options like <firewalled/>
> 
> btw, my jabberfs:iq:filetransfer is not so complicate. in general it´s 
> nearly the same as jabber:iq:oob. maybe we can accept it as an 
> alternative way to passing url/ it passes the ip + port
> as well as some additional file information  (because i consider the 
> jabber xml as a good control way for the transfer)
> 
> cya, Edrin





More information about the JDev mailing list