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

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

	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
source tree sometime early next week.  I'm also disecting using the same
expat sources you are using for parsing the XML, making it a bit easier to
look at the client.

	I've also figured out a way to tentativly do file transfers via messages..
What I've worked out is to have the client UUENCODE the file, then send it
in chunks of message tags, like this:

<message type='wintransfer'>
  <to>TwOlf</to>
  <ext>
    <tranfernum>82646</transfernum>
    <filename>somefile.txt</filename>
    <totalpackets>100</totalpackets>
    <packetnumber>10</packetnumber>
    <totalfilesize>1074</totalfilesize>
    <data>HJFGSHGFSGFHGY67835627T4HGDY5</data>
  </ext>
</message>

	Here is a brief rundown of how I'm looking at doing it, and what the tags
mean:

<message type='wintranfer'>
Used this to pass thru as a message, but a type of wintranfer.  Used
wintransfer so it does not interfere with anything anyone else is working
on, aka, I'm fine as long as no one else uses this type.

<to>TwOlf</to>
Obviouse..  Who this packet is going to.

  <ext>
Storing all of my data in the ext tag..  Good question here, though..  It it
acceptable to have additional XML tags within the ext tag?

    <tranfernum>82646</transfernum>
A Randomly generated number to 'identify' this transfer

    <filename>somefile.txt</filename>
Filename being transfered..  (May be saved differently, but this is what it
WAS called)

    <totalpackets>100</totalpackets>
Total packets in this transfer.. Basically, I uuencode the file and split
the resulting set into X number of chunks, each being a certain size (What
do you think would be optimal for the servers to handle correctly? I'm
assuming something smaller, so 10 transfers don't result in one server
bogging memory wise)

    <packetnumber>10</packetnumber>
Current packet number..  This instance is packet #10 of 100 total.

    <totalfilesize>1074</totalfilesize>
The total size of the uuencoded data.  Used to validate that it came thru
OK..

    <data>HJFGSHGFSGFHGY67835627T4HGDY5</data>
The uuencoded data.

	Will all this be acceptable via the servers?  I BELIEVE so, but I'm
stilllooking thru the transport and jabberbox source to ensure so..

	I'm also considering adding a 'response' packet, so 100 packets aren't
sent, the user get's 50, signs off,and the person who sent them get's 50
'rejected' messages becouse they couldn;t be delivered, but that would
require using additional bandwidth.

	The other neat idea would be to be able to send messages as above to
offline users, which would, in turn, be stored offline, and would allow file
transfers tooffline users, as the<message>'s would still be stored on the
server, but it would require turning 'off' the need for a response for each
packet, which is OK, but it'd mean you'd need some sort of tag in ext to
tell the server NOT to send a 'This user is offline' message.

	Also, I've noticed the 'invite' that is checked in <ext>.  Should this now
be moved to <message type='invite'> instead of having jabber.transport check
the <ext> tag for invite?

	Ideas?  Comments?  People who want me to STOP asking questions and just
shut the heck up?  ;-P

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


> -----Original Message-----
> From: owner-jdev@jabber.org [mailto:owner-jdev@jabber.org]On Behalf Of
> Jeremie
> Sent: Friday, March 26, 1999 4:36 PM
> To: jdev@jabber.org
> Subject: [JDEV] jabber.org updated
>
>
> http://jabber.org/
>
> I just updated a few pages and restructured some other areas of the site.
> Feel free to take a peak and let me know if there are any glaring
> problems, spelin mistakes, broken links, etc...
>
> Warning: there are quite a few empty pages that I'll be filling in with
> documentation yet, RSN!
>
> DR 0.6 with the new protocol will be out either before the end of March or
> in very early April, joy!
>
> Thanks,
>
> Jer
>