> I think the iq:oob is the right place for this.  I've devised a fairly
> simple way to ensure that the person making the connection is the 
> appropriate person.  I've explained it a few times on this mailing list,
> I can explain it again if necessary.
>
> About the firewall issue.  I haven't spent any time on this issue yet, 
> if there is a firewall between the sending and the recipient, then I 
> just show an error message. I know that some people and some other IM
> clients use temporary disk web server to store stuff.  Something about
> WebDav.  When I do get around to solving this, I don't think this is
> how I'll solve the firewall problem.  I'm thinking that managing the
> lifetime of others files and making sure their secure will be too
> difficult.
>
> Instead, I think I'll just build another mini-web server or maybe an
> NSAPI or ISAPI DLL that both senders and recipients will connect to
> simultaneously to send a file.  When the sender decides to send a file,
> the client will first connect to this server and do a post that tells
> this web server that it wants to send a file.  This web server will 
> respond with a unique URL that the client will use to give to the
> recipient.   The client will remain connected to this web server, and
> then send a iq:oob to the recipient, with the corresponding URL.  The
> recipient client will then connect to that web server and do a GET
> on that URI.  Once the recipient is connected, then he will send an
> iq:oob result back to the sending client.  When the sending client gets
> this, it will start pushing the file to the web server.  Once its done,
> it will close up the connection.   The web server will pipe the data
> it gets from the post back to the recipient's connection.  The recipient
> will GET the file and everyone is happy.
>
> How does this sound?
>
> -Robert

But that would be incompatible with the current systems...
Wouldn't it be easier to send the senders ip as part of an url then as
soon as the other client connects to this and requests the file (an
http get) the sender stops listening on that port. So while it would
be possible for a third party to get the file by eavesdropping on the
conversation and grabbing it before the other client does it would be
quite unlikely :)
That way would remain compatible with the other way being used in
clients like JabberIM and WinJab, the receiver does not need to know
whether he/she is downloading directly from the sender or via a third
party.

Thomas Parslow (PatRat) ICQ #:26359483
Rat Software
http://www.rat-software.com/
Please leave quoted text in place when replying



_______________________________________________
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev

Reply via email to