Re: [Standards] pep & avatars
On Thu, Mar 26, 2009 at 1:28 PM, Pedro Melo wrote: > > I understand, but if the cost of sending those "my current item is this" > with presence if greater than just receiving the item at start (not the > image data, just the metadata), then this discussion is moot, right? I haven't explained well. It's not "my current item", just my client uuid is[1]. I'd like to be able to do the same with the pair (ext, jid) from the capabilities, but if I use the same client with same resource on a different pc with PEP I've no way to recognize the client hasn't been synchronized. And for this things like sequencing aren't good, since basically you always send the last version for each node. [1] this requires keeping a bit more of context at server side, but I think it is marginal. We are experimenting it with a facebook gw and it is rather easy to maintain > >> On the single event we have a >> gain of the 50 - 60% of the data which is not a lot, but there many >> random strings in the message. A good guess, with the entropy of the >> previous messages, could be 150-200 bytes per user, which is still a >> lot: if you have 100 online contacts it's 15K just for knowing that >> nothing has changed.> > but you would have to send the UUID of each of those contacts to tell each > of those PEP nodes which version you have, right? > > If I have N contacts, and each one of them uses PEP for avatar and user > tunes, when I start a new session, I would need to send to each PEP node my > current UUID so that they know which version I have before they send me the > current version. > > So I would have 200 stanzas just to communicate my "current cached status", > via the upload link, usually on the lowest bandwidth side. > > Or I could receive notifications from all those PEP nodes telling me "this > is the version I got", from the larger bandwidth side. > > I admit that I haven't read these XEP's lately and I'm might be missing > something... See above, just one uuid, bound to the client, not to subscribed nodes. Some quick figures: - present scenario (just for avatars, with more nodes it gets worse): I go online with 100 online contacts and I receive the latest item version -> ~15K - proposed scenario (worst case): all my 100 contacts put client uuid in their capabilities in their presence -> 25 byte * 100 -> ~ 2.5K and nothing more if avatars haven't changed. In order to waste bandwidth more than the 80% of the contacts must have changes avatar, while in the normal situations (no avatar changed) I save the 80% of the traffic -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] pep & avatars
On Mar 26, 2009, at 12:02 PM, Fabio Forno wrote: On Thu, Mar 26, 2009 at 12:44 PM, Pedro Melo wrote: Also, do you have any data on the size of those 500 and 100 bytes after compression? Well... big numbers are more impressive :D I don't want to consider vcard avatars, since I'd like to have a general mechanism for other things too. I understand, but if the cost of sending those "my current item is this" with presence if greater than just receiving the item at start (not the image data, just the metadata), then this discussion is moot, right? On the single event we have a gain of the 50 - 60% of the data which is not a lot, but there many random strings in the message. A good guess, with the entropy of the previous messages, could be 150-200 bytes per user, which is still a lot: if you have 100 online contacts it's 15K just for knowing that nothing has changed. but you would have to send the UUID of each of those contacts to tell each of those PEP nodes which version you have, right? If I have N contacts, and each one of them uses PEP for avatar and user tunes, when I start a new session, I would need to send to each PEP node my current UUID so that they know which version I have before they send me the current version. So I would have 200 stanzas just to communicate my "current cached status", via the upload link, usually on the lowest bandwidth side. Or I could receive notifications from all those PEP nodes telling me "this is the version I got", from the larger bandwidth side. I admit that I haven't read these XEP's lately and I'm might be missing something... Best regards, -- Pedro Melo Blog: http://www.simplicidade.org/notes/ XMPP ID: m...@simplicidade.org Use XMPP!
Re: [Standards] pep & avatars
On Thu, Mar 26, 2009 at 12:44 PM, Pedro Melo wrote: > > I understand your problem, but do you really want to send that with all the > 's or just the initial one? That's one of the things worth discussing ;) I guess it is more conservative to send the uuid for each presence. An additional field in the capabilities could be more efficient since we save a new XML element and a namespace declaration > Also, do you have any data on the size of those 500 and 100 bytes after > compression? Well... big numbers are more impressive :D I don't want to consider vcard avatars, since I'd like to have a general mechanism for other things too. On the single event we have a gain of the 50 - 60% of the data which is not a lot, but there many random strings in the message. A good guess, with the entropy of the previous messages, could be 150-200 bytes per user, which is still a lot: if you have 100 online contacts it's 15K just for knowing that nothing has changed. Moreover the gain is not just for avatars, but for any PEP node, with very little work at server side and breaking nothing with clients non supporting it (if there is no uuid we just send the notification) -- Fabio Forno, Ph.D. Ooros srl jabber id: f...@jabber.bluendo.com
Re: [Standards] pep & avatars - photo upload script?
Sorry to hijack the thread but Has anyone on this list used/built some kind of snazzy upload a photo and move the square box over the photo to capture the size we want kind of script or something like this? Have you opensourced it or can we license the java from you at a reasonable price? Seems like such a fundamentally reusable piece of software surprised I haven't been able to find something. Regards, Dean Collins Cognation Inc d...@cognation.net +1-212-203-4357 New York +61-2-9016-5642 (Sydney in-dial). +44-20-3129-6001 (London in-dial). -Original Message- From: standards-boun...@xmpp.org [mailto:standards-boun...@xmpp.org] On Behalf Of Pedro Melo Sent: Thursday, March 26, 2009 7:44 AM To: XMPP Standards Subject: Re: [Standards] pep & avatars Hi, On Mar 26, 2009, at 10:54 AM, Fabio Forno wrote: > Hi, > we're implementing user avatars with our mobile client and we're > trying to do that with bandwidth issues in mind. > According to xep-163 the only reliable way to sync items (avatar > version) is sending the latest item to each user session, then if the > clients notices a change it can retrieve the avatar. For mobiles this > is rather heavy since the average pep notification is 500 bytes, while > the vcard-temp:x:update child in the presence is just 100 bytes, and > both must be sent each user session. This means that for mobiles it is > far better using the old vcard based protocol, approach I don't like > since PEP is much more useful. Therefore I'm trying to think of a way > to reduce the item notifications and send them only when they are > really changed, not to each user session. So far the best way I > thought of is extending client presence with an uuid identifying the > client instance, so that the PEP service can figure out whether that > client has already been updated. > > Example: > > > > > > > The pep service matches the uuid for each node the client is > subscribed to and, if it hasn't sent the latest item to that uuid it > sends an event notification, otherwise it does nothing, avoiding > sending redundant data. I understand your problem, but do you really want to send that with all the 's or just the initial one? Also, do you have any data on the size of those 500 and 100 bytes after compression? Best regards, -- Pedro Melo Blog: http://www.simplicidade.org/notes/ XMPP ID: m...@simplicidade.org Use XMPP!
Re: [Standards] pep & avatars
Hi, On Mar 26, 2009, at 10:54 AM, Fabio Forno wrote: Hi, we're implementing user avatars with our mobile client and we're trying to do that with bandwidth issues in mind. According to xep-163 the only reliable way to sync items (avatar version) is sending the latest item to each user session, then if the clients notices a change it can retrieve the avatar. For mobiles this is rather heavy since the average pep notification is 500 bytes, while the vcard-temp:x:update child in the presence is just 100 bytes, and both must be sent each user session. This means that for mobiles it is far better using the old vcard based protocol, approach I don't like since PEP is much more useful. Therefore I'm trying to think of a way to reduce the item notifications and send them only when they are really changed, not to each user session. So far the best way I thought of is extending client presence with an uuid identifying the client instance, so that the PEP service can figure out whether that client has already been updated. Example: The pep service matches the uuid for each node the client is subscribed to and, if it hasn't sent the latest item to that uuid it sends an event notification, otherwise it does nothing, avoiding sending redundant data. I understand your problem, but do you really want to send that with all the 's or just the initial one? Also, do you have any data on the size of those 500 and 100 bytes after compression? Best regards, -- Pedro Melo Blog: http://www.simplicidade.org/notes/ XMPP ID: m...@simplicidade.org Use XMPP!
[Standards] pep & avatars
Hi, we're implementing user avatars with our mobile client and we're trying to do that with bandwidth issues in mind. According to xep-163 the only reliable way to sync items (avatar version) is sending the latest item to each user session, then if the clients notices a change it can retrieve the avatar. For mobiles this is rather heavy since the average pep notification is 500 bytes, while the vcard-temp:x:update child in the presence is just 100 bytes, and both must be sent each user session. This means that for mobiles it is far better using the old vcard based protocol, approach I don't like since PEP is much more useful. Therefore I'm trying to think of a way to reduce the item notifications and send them only when they are really changed, not to each user session. So far the best way I thought of is extending client presence with an uuid identifying the client instance, so that the PEP service can figure out whether that client has already been updated. Example: The pep service matches the uuid for each node the client is subscribed to and, if it hasn't sent the latest item to that uuid it sends an event notification, otherwise it does nothing, avoiding sending redundant data. -- Fabio Forno, Ph.D. Ooros srl jabber id: f...@jabber.bluendo.com
