[JDEV] File Transfer Proposals

[Philippe Raxhon]

Just a question: can this "design" be used to do file transfer with 
other IM like ICQ (I don't know how they do it)?

Julian Missig wrote:

>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
>>
>
>
>_______________________________________________
>jdev mailing list
>jdev at jabber.org
>http://mailman.jabber.org/listinfo/jdev
>
>