You dont need HTTP or FTP because they are way too bloated as I have already said, I come to this conclusion because they all have far more features than are necessary, what other than resuming is really needed ?? The method I mentioned is nice and simple and does the job and can easily support resuming using the control messages I mentioned that can be passed along the xml stream, now although there wont be a library around for this why would you need one, I dont know about anyone else but it would not take me anymore than 2 maybe 3 hours to code that in C++. Instead of just using other protocols just because they are there and trying to do a hack around what they are really designed for just to use them, why not just spend that time producing this simple basic protocol which is all is really needed, there is no stopping people having HTTP functionality in their clients but for much more universal compatibility with all types of clients lets use something like this as a common basic/light protocol designed specifically for the task at hand and not a bloated possibly insecure (depending on the implementation, which if libraries were used that were produced for academic assignments are probably not the most secure thing to use, rushed etc) protocol that was designed for a different purpose. Also I dont know about anyone else but I do not want to have an HTTP server running in my app, that just invites hacking or attack, and the way it has been suggested it be implemented it would have to be running all the time consuming CPU power, which on small devices could be a problem, im not saying that some client authors cant do file transfer that way too but there needs to be a common method suitable to all devices and HTTP is not it.
----- Original Message ----- From: "Julian Missig" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, February 18, 2002 8:08 PM Subject: Re: [JDEV] File Transfer Proposals > If all you're doing is sending or receiving a file, I really don't think > HTTP or FTP are too bloated. In the end, after you've reimplemented > every feature from HTTP/FTP we'll want, like resuming, the amount of > work put in to creating such a protocol will be so much more than just > using HTTP and FTP. Don't tell me you can't find a library to add HTTP > or FTP support. I'm fairly certain that most people getting a CS degree > have to write one or the other at some point in their studies, so it's > not like they're impossible to find. > > Julian > > On Mon, 2002-02-18 at 06:35, Richard Dobson wrote: > > The main problems I see are that HTTP/FTP are far too bloated protocols, all > > is really needed just like msn, icq, and aim is just a basic protocol for > > sending the file p2p, thats what IM file transfers are, you dont need all > > this storing of files for offline users and uploading to HTTP servers, if > > someone wants to send a file to someone who is offline they will email it to > > them, if someone wants to put the file up and lets lots of people access it > > they will upload it to their website, there is no need to make this a > > hundred times more complicated than it needs to be, all IM file transfer > > needs to be is a quick way to send files p2p, and the best way I see of > > doing that is just opening up a socket, get the other person to connect and > > then just stream the data to them, maybe with a few control messages sent > > over the xml stream, and if they are behind NAT's and could not connect then > > just make it automatically retry using PASS instead of a direct connection, > > lets just keep this simple guys. This way it keeps things simple you dont > > have to have the bloat and insecurity of having a HTTP/FTP server/client > > software built into the client, it also helps keep things more legally > > safe/secure as the files are not being saved anywhere other than on the > > machines of the two people sending/receiving the file, and also saves on > > having to setup all sorts of webdav storage servers and all the unnesessary > > complexity and cost thats involves. > > > > Well just my 2p. > > > > Rich > > > _______________________________________________ > jdev mailing list > [EMAIL PROTECTED] > http://mailman.jabber.org/listinfo/jdev > > _______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
