[JDEV] Buddy icons & File Transfer

[Robert Temple]

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

-----Original Message-----
From: Jens Alfke [mailto:jens at mooseyard.com]
Sent: Monday, March 26, 2001 11:00 PM
To: jdev at jabber.org
Subject: Re: [JDEV] Q: Buddy icons?


Thomas Muldowney <temas at box5.net> wrote:

> This seems as if it could be implemented with a iq:oob style namespace.

Maybe, but since a typical buddy icon will be a 32x32 pixel image, which
will be ~2k bytes in size as a GIF/JPEG/PNG, I don't really think it's worth
the overhead of opening up a separate oob connection for it.

(Also, I'm not convinced based on what I've read that oob is ready for prime
time. Direct client-client communication won't work through firewalls or
NAT, which means I personally can't use it either at work or at home. It
also implies giving out your IP address, which some people are loath to do
for security reasons. I'm also unclear on how you manage access control: how
do you know that the person making an HTTP connection to you is the person
you sent the IM to?)

Eliot Landrum wrote:

> vCard supports this type of stuff.. would that be an appropriate place
> to put it?

You're right, I hadn't thought of that. I think the vCard element is called
PHOTO. So a standard <iq> request with a <vcard> element would work to get
this.

The drawback is that this kind of assumes the picture is fixed forever;
otherwise some kind of polling (even if only once per login) is necessary,
since there's no notification if it ever changes. Why might it change? To
daydream, let's say I want my client to allow my icon to change when my
status does: my "do not disturb" icon might be a picture of me with an open
copy of "BSD For Dummies" held in front of my face. :) Or the picture for
the canonical online coffee maker might be an icon of a coffee pot with the
current degree of fullness.

One possibility to enable this is to send the icon [or just an indication
that it's changed] as part of a state change, i.e. some new sub-element of
<presence>. This allows the icon to change dynamically for any reason,
without requiring watchers to poll. The sub-element could be
<photo>...</photo> with ~2k of raw CDATA in between, or a simple
<photo-changed/> with no content.

The drawback of this is that I'm guessing it requires server modifications
to store the image, unless the server just slurps up the entire <presence>
element and will relay any kind of sub-elements to watchers without
interpreting them?

--Jens


_______________________________________________
jdev mailing list
jdev at jabber.org
http://mailman.jabber.org/listinfo/jdev