[standards-jig] NEW: User Avatars (JEP-0084)
jabber at dsutton.legend.uk.com
Thu May 8 13:35:19 UTC 2003
In accordance with the business section regarding Presence in
JEP-0045, MU-Conference will only strip extended MUC presence
information if sent by the client (for security and sanity reasons) All
other extensions to presence are not touched.
However, with the current jabberd structure, I must advise against
overload presence with data such as avatar, music, etc. The more that is
added, the smaller the lower room limit before the service starts
slowing down. This will also cause room entry/leave times to grow
faster. This isn't something I can do much else about, as the issue is
with pth. I would also point out that mu-conference is a packet
multiplier - so your one message is duplicated x number of times - make
the packet bigger, and the bandwidth goes up.
I would therefore have to say that room registration and distribution
that way would be far better for everyone concerned.
On Thu, May 08, 2003 at 03:14:03PM +0200, Heiner Wolf wrote:
> I totally agree with disco/pub/sub for IM/P.
> I just want to make sure that the new conference component distributes
> <presence/> untouched for existing clients. I don't want it to obey the
> avatar JEP too much and rip off avatar tags, because they are not
> David can you comment on that?
> Dr. Klaus H. Wolf
> bluehands GmbH & Co.mmunication KG
> +49 (0721) 16108 75
> > -----Original Message-----
> > From: David Sutton [mailto:jabber at dsutton.legend.uk.com]
> > Sent: Thursday, May 08, 2003 2:37 PM
> > To: standards-jig at jabber.org
> > Subject: Re: [standards-jig] NEW: User Avatars (JEP-0084)
> > Hello all,
> > *wince* Let me put it this way, I would not be happy with
> > the approach
> > of the conference component acting as detailed below, as I
> > think this is
> > a waste of both bandwidth and storage resources. It takes a lot of
> > processing already whenever a user enters or leaves a conference room,
> > and this would just make the whole situation FAR worse.
> > In fact, I do not believe that conferencing avatars should
> > be covered
> > in this JEP, instead they should be covered by a MUC services
> > extension
> > JEP. The best I would be happy with is allowing a user to
> > register with
> > a room/service and allowing them to have their avatar hash stored in
> > that data. When a new user connected, I could walk the
> > members hashtable
> > and send them avatar packets if they are registered and have 'avatars'
> > enabled. There are going to be rooms where avatars can be banned, and
> > this would allow control to be maintained.
> > Regards,
> > David
> > On Thu, May 08, 2003 at 02:07:38PM +0200, Jacek Konieczny wrote:
> > > On Thu, May 08, 2003 at 01:32:44PM +0200, Heiner Wolf wrote:
> > > > The concern is about this scenario:
> > > > - 100 users in a room
> > > > - 1 user joins and sends avatar digest in <presence/>
> > > > - conf component distributes the <presence/> tag.
> > > > - 100 users compare their digest with the new one and
> > fetch the avatar,
> > > > if digest is old.
> > > >
> > > > It would be a mess, if all users would start to disco any
> > time 1 users
> > > > enters a room:
> > > > - 100 users disco the new user
> > > > - the new user discos 100 others
> > >
> > > Maybe the conference component should disco users and reply to disco
> > > requests for them. It is proxying most of the trafic in a
> > similar way
> > > anyway.
> > >
> > > People in conference room are resources of conference
> > component's jid,
> > > so it seems the right entity do reply disco requests.
> > >
> > > Greets,
> > > Jacek
> > > _______________________________________________
> > > Standards-JIG mailing list
> > > Standards-JIG at jabber.org
> > > http://mailman.jabber.org/listinfo/standards-jig
> > --
> > David Sutton
> > Email: dsutton at legend.co.uk
> > Jabber: peregrine at legend.net.uk
> Standards-JIG mailing list
> Standards-JIG at jabber.org
Email: dsutton at legend.co.uk
Jabber: peregrine at legend.net.uk
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the Standards