RE: [JDEV] Win client, File Transfers, invite tag..

["Thomas Charron" <tcharron@nermail.ups.com>]

> From: owner-jdev@jabber.org [mailto:owner-jdev@jabber.org]On Behalf Of
> Jeremie
> Subject: Re: [JDEV] Win client, File Transfers, invite tag..
> > 	I will promise to at least have a Windows test client ready
> by then.  I've
> > been unfortionatly busy as heck, and haven't had any time to
> have a working
> > client with the new protocol complete.  Looks for a big Win32
> checkin to the
> Excellent on all of the above points!  The C in /lib/* should be mostly
> XP, so you might want to look at just using the whole common lib... but
> there might be some excellent reasons not to for win32 stuff.

	Yea, looking at it, I'm going to try to reuse as much of the command line
code as possible to keep things as the 'same' as possible.  The primary
difference is I can easily multithread the backend, and keep it seperate
from the UI.. ;-P

> HTTP/1.1
> Yup, that's right... let's use HTTP/1.1!  It already has EVERYTHING needed
> to handle any type of file transfer, and it's commonplace, and it works.
> Here's how, simple version:
> 	user x sending file to user z
> 	z recieves message and uses HTTP/1.1 to GET file

	Only one problem (Which someone else has already pointed out..  Yes, I
cheat and read ahead.. ;-P).  This make a client to client connection, and
broadcasts the IP address to clients.  I know, you're addressing it via a
transport.  (Notice the other message regarding transport overload, as well,
though)..

> Ok, benifits:
> 	HTTP/1.1 can do resumes if it get's broken.
> 	ICQ/AIM transports could impliment "translator" daemons for it
> 	Recieving client could just spawn browser to fetch file
> 	Happens in background, leaves Jabber connection to work normally
> 	This could be simply a URL message, not specific for files

	I like it..  For ordinary file transfers, and a transport of some sort,
this would be wonderful.

> 	A special module could be written on the Jabber server to use this
> functionaliy for a "file archive".  The client would send a jabber message
> to the module and ask for a repository, this would be configurable
> obviously so only special users could use it or have size limits. The
> module would reply with an: http://serverIPaddress:port/.  The client
> would then PUT files up there via HTTP, and authenticate them with the
> users username/password.  Then it would send out the location to GET them
> like any other file message as above.  This would allow you to send files
> to offline users, as well as send files to groups of users, just upload it
> once and they all download it.  It is also a solution for transferring
> files if you are going through a firewall.  Actually, it could end up just
> being a normal apache and a special module or similiar... and you'd have
> your own personal webspace...

	This I REALLY like..  You could actually automate client upgrades this way,
but having a server send out a file get message to users clients who have
'registered' with a transport to recieve update file announcements.

	Heck, a company could use features like this to use jabber client/server as
their 'support' system fairly easily.  Build in basic jabber support into
the program, and users can communicate via jabber for technical support,
file upgrades, new announcements, etc..

> There are some issues here yet, but I think this is the best way to go in
> some form.  I've really gotta sit down and think this through clearly and
> get it written down, but hopefully this will get the discussion started :)

	Please do..  I LOVE the idea itself, but I can still see holes that needs
to be addressed.

--
Thomas Charron
United Parcel Service
Northeast Region
"Moving at the speed of a T3 Trunk Line!"