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
