[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