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, [EMAIL PROTECTED] 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 >[EMAIL PROTECTED] >http://mailman.jabber.org/listinfo/jdev > > _______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
