[JDEV] Two more avatar issues.

[Jens Alfke]

On Thursday, September 6, 2001, at 04:31 PM, David Waite wrote:

> What we really have here is a need for subscribing to more than just a 
> user's sessions, but to also to indicate interest and get published 
> updates for other user data and session data. Presence just isn't 
> fine-grained enough for that. If we had something fine-grained, you 
> could just as well serialize the data within the push, rather than 
> trying to use a hash to save bandwidth.

I strongly agree that <presence> is much, much too single-purpose! It 
was hardcoded to manage two specific pieces of state (status and 
message), but doesn't extend to anything else. I think it's well worth 
thinking about a design that will allow it to be extended into a generic 
"publish/subscribe" model for arbitrary data.

> On a different note,  what is the benefit of being able to define an 
> avatar for different resources? It seems like what a user wants is to 
> see the same picture for the same person everytime.

Oh, there are lots of good reasons for per-resource avatar pictures, 
mostly having to do with using a more dynamic set of pictures rather 
than a single fixed one:

[1] I might want to use a different picture for different locations. For 
example my "/Work" picture might show me in a 3-piece suit (yeah, right) 
while in the "/Home" picture I'm wearing a Hawaiian shirt. Maybe my 
"/Phone" resource is a photo of me talking into my cellphone? Besides 
being cute this also lets people tell at a glance which location I'm 
most active at. (My client has an optional micro-buddy list that's a 
floating window containing nothing but 32x32 buddy pictures.)

[2] Similarly, I might want to use a different picture for each status 
mode. Regular picture for "available", holding a book in front of my 
face for "busy", asleep for "xa", etc. Clearly this is specific to a 
particular resource, just as presence status is.

[3] The picture might be driven by a webcam and updated once a minute. 
Clearly this is specific to one location.

[4] It avoids annoying synchronization issues. If I'm offline and change 
my picture, then log in, should I upload the changed picture or download 
the current one from the server? Unless we timestamp the picture on the 
server, it seems difficult to decide which one is more recent. (I have a 
similar issue about vCard storage, too.)

Yes, I am fairly serious about trying to implement [1] and/or [2] once I 
get the basic buddy icon support working (any day now...)

--Jens