[JDEV] Avatar images are per-resource

temas temas at box5.net
Wed Sep 5 16:36:47 CDT 2001

On Wed, 2001-09-05 at 16:11, Jens Alfke wrote:
> On Wednesday, September 5, 2001, at 12:34 PM, temas wrote:
> > Good thoughts, have you tested at all aginast the server?
> Not yet. I had to finish up implementing feature #n-1 before I could get 
> to this one. But I've started coding now.
> > If the avatar is *not* per-resource, all we'll have to do is write it 
> > up in the spec that clients *must* check for an existing avatar before 
> > uploading a new one... and show that avatar to the user. If it *is* 
> > per-resource, we're going to waste a lot of server space. - Unless we 
> > up the complexity one notch and have some sort of expiration of 
> > avatars, I guess. But my vote is for the simpler method.
> How much server space do we really waste? Remember that we have agreed 
> on an 8k limit for the pictures (and in my experience the JPEGs will be 
> about 2k). It takes a lot of those to eat up any meaningful amount of 
> storage.
> I would be sad if we had to make avatars per-account. That prevents you 
> from doing many creative things like
> - showing a picture appropriate for the location (i.e. wearing a suit 
> for at work, a Hawaiian shirt for at home)
> - showing a different picture per state (or just for whatever reason, 
> like happy or sad faces)
> - periodically updating your picture from a live webcam
> —Jens

Yes, it may be a small amount of data but that doesn't excuse us from
fully considering it's impact.  What happens when you have millions of
users and each one has multiple resource.  It's hard to tell but I have
some proposals, although these aren't implemented currently, we are
looking at new Data Management components (XDB++).  What if per resource
data stored int he DM was only persistent through the life of that
resource, but data stored for the user at server scheme would be always
there.  To further enhance this we could make it so that if a
user at server/resource lookup fails, then it could fall back on the
user at server data if it is available.  Again, this would be future, but
who know, I might convince jer to do it for 1.4.2.  Thoughts?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/jdev/attachments/20010905/f4130ae9/attachment-0002.pgp>

More information about the JDev mailing list