[JDEV] Avatar: no per-resource public XML storage in 1.4.1

[temas]

Ok, I talked with jer about this a bit, and currently all packets bound
to a resource are delivered directly to that resource.  The reasoning is
that the resource is a specific instance of the jid, and so traffic is
specifically sent to it.  I can understand this and see why it makes
sense, so I'm not arguing it.  He did say he would look at the resource
fallback to the primary though.

On another note I've been pondering this and some other issues that
David Waite eluded to in his post for the future of data management like
this.  I've been wondering if there isn't a possible common ground for
some of these data tasks that are bound to a resource (avatar, version,
and others).  It seems that the Data Management Component (XDB ng) could
potentially cache some of this information that has specific triggers
for when it will be changed (avatar hash update, or resource disconnect)
and then republish it based on a set of ACLs (similar to David Waite's
post previously).  This way the client wouldn't have to respond to a
continual flurry of these, but potentially just one and it would then be
cached.  I'm still not sure if this is a great idea, but it is something
to explore for the future.

--temas


On Thu, 2001-09-06 at 19:10, Jens Alfke wrote:
> Looks like Jeremie was a bit off base in his description of public XML 
> storage; or it wasn't implemented correctly. When I tried to store the 
> avatar picture data on my own resource, the server (1.4.1 Solaris) just 
> bounced it back to me as it would any regular IQ query.
> 
> I sent:
> <iq type="set" id="00000003" to="jens at myserver/myRsrc">
> <query xmlns="jabber-storage:iq:avatar">
> <data mimetype="image/jpeg">
> /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDABALDA4MChAODQ4SERATGCgaGBYWGDEjJR0oOjM9PDkz 
> .......
> </data></query></iq>
> 
> and I promptly got back:
> 
> <iq type='set' id='00000003' to='jens at myserver/myRsrc' 
> from='jens at myserver/myRsrc'>
> <query xmlns='jabber-storage:iq:avatar'>
> <data mimetype='image/tiff'>
> /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDABALDA4MChAODQ4SERATGCgaGBYWGDEjJR0oOjM9PDkz 
> ......
> </data></query></iq>
> 
> I'm assuming from this that the data didn't get stored on the server. :-(
> 
> Looks as though our options are:
> (1) Don't use server-side storage for avatar pictures; the client has to 
> respond to the queries. This is the way it was in the original spec. 
> It's flexible but causes bandwidth problems for dial-up clients and 
> doesn't allow you to get the picture of an offline user.
> (2) Make avatar pictures per-account, not per-resource, and gain 
> server-side storage but lose interesting features.
> (3) Fix the server's public XML storage implementation to store resource 
> data (and make it nonpersistent as temas suggested)
> (4) Add a server module specifically for storing avatar pictures.
> 
> For now I'm going to implement according to (1) or (2) since I have no 
> desire personally to muck with the server code! In the long run I guess 
> I would prefer (3) to (4) because I would rather see an existing generic 
> facility improved rather than add Yet Another Special Purpose Hack to 
> the server.
> 
> --Jens
> 
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <https://www.jabber.org/jdev/attachments/20010907/f4d241d1/attachment-0002.pgp>