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

temas temas at box5.net
Thu Sep 6 22:52:34 CDT 2001


I'll play with this some tomorrow and let everyone know what's up.  If
possible I may try to put together a patch to give to jer for 1.4.2 of
my storage idea.  Pending his approval of course.

--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/20010906/801f1d3f/attachment-0002.pgp>


More information about the JDev mailing list