[jdev] Re: web presence (Brijesh Singh)
Singh, Brijesh (GDIC)
brijesh.singh at hp.com
Mon Mar 13 23:41:27 CST 2006
I think ur approach is good... May be little deviation will help to
resolve presence freshness issue...
a- Subscribe presence(bcc) in new external web presence component.
b- Create a map of jid => presence in process memory so that access is
faster while accessing or showing it to web component.
c- Update the same presence to DB also to backup the presence
information.
This approach will always show latest presence of users...
Case 1 :- If jabberd server goes down then new web presence component
will also loose it connectivity and will go for graceful shutdown(update
DB)... Nothing to worry because all users are offline now. This time web
application should show all the users offline. When jabberd again
restarts, then it will get a new set of presence info. Follow the step
"a-c ".
Case 2 :- If only external presence web component goes down then bcc
module will not send all the users presence again, it will only send the
changed presence but you need old presence information also. Here you
need the help of DB to extract all previous presence data from DB.
d- Read the data from DB
e- Get the new presence information, which will be send by bcc module.
Case 3:- If any users got deleted then you are not going to get the
presence information from jabberd...
To solve case -2 problem(U will read all the user info in case component
goes down, which may read deleted user as well), Write a DB trigger for
jabber database, i.e. if any user get deleted from DB then delete it
from ur new presence table also.
Hope it will give more thoughts to u....
Best regards
Brijesh Singh
>We have previously developed such a component for an internal project
using the component approach and a database - we used presence bcc to
>get all presence updates.
>Somethings to keep in mind around freshness of presence information.
>When the jabber server restarts - all your existing information in the
DB is stale. You may want to detect this and purge the presence store.
Similar >cases arise when there is loss of connectivity between the
component cases. User accounts may get deleted on the IM server and you
may need >to synchronize that on your database also.
>Over time, I have found that such a presence server capability is best
built "directly" into the IM server with tight integration with the
presence
>processing and subscriber management modules. This way you benefit from
privacy policies that are available in the same place.
>YMMV.
-----Original Message-----
From: jdev-bounces at jabber.org [mailto:jdev-bounces at jabber.org] On Behalf
Of jdev-request at jabber.org
Sent: Tuesday, March 14, 2006 1:15 AM
To: jdev at jabber.org
Subject: jdev Digest, Vol 26, Issue 25
Send jdev mailing list submissions to
jdev at jabber.org
To subscribe or unsubscribe via the World Wide Web, visit
http://mail.jabber.org/mailman/listinfo/jdev
or, via email, send a message with subject or body 'help' to
jdev-request at jabber.org
You can reach the person managing the list at
jdev-owner at jabber.org
When replying, please edit your Subject line so it is more specific than
"Re: Contents of jdev digest..."
Today's Topics:
1. Re: web presence (Peter Saint-Andre)
2. Re: web presence (ennova2005-jabber at yahoo.com)
3. Re: Resource binding limit(ation) (Peter Saint-Andre)
4. Re: web presence (Hal Rottenberg)
----------------------------------------------------------------------
Message: 1
Date: Mon, 13 Mar 2006 11:02:28 -0700
From: Peter Saint-Andre <stpeter at jabber.org>
Subject: Re: [jdev] web presence
To: Jabber software development list <jdev at jabber.org>
Message-ID: <4415B3B4.1040800 at jabber.org>
Content-Type: text/plain; charset="iso-8859-1"
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
+1, that seems like a sensible approach.
/psa
Peter Millard wrote:
> This is exactly how I would implement this as well.
>
> 1) Have an external component that uses iq:register protocol with
> x-data for picking themes, etc. This component subscribes to the
> user's presence during registration (just like a transport does). Now
> the component has the users presence.
>
> 2) External component pushes presence info into a database (mysql,
psql, etc).
>
> 3) Write a quick PHP applet or something which returns an image based
> on the JID.
>
> We could easily deploy something like this on jabber.org provided the
> DB is psql, and the component is not in Java or Perl (for scalability
> issues). Seems like this would be super easy to write using the
> Twisted Python jabber component stuff.
>
> This approach would also work with any server implementation since the
> component is subscribing to the user's presence.
>
> pgm.
>
> On 3/9/06, Richard Dobson <richard at dobson-i.net> wrote:
>>> It would be good if we had standardized methods for embedding
>>> presence information in web pages. For example, I'd like to be able
>>> to point to the following image file and have it show my presence:
>>>
>>> <img src='http://www.jabber.org/users/stpeter.png'/>
>>>
>>> Granted there are challenges here:
>>>
>>> 1. Needs to be opt-in (no presence leaking)
>>>
>> Have it as a contact on the users roster which represents the
>> presence service, if that contact can see the users presence the user
is opting in.
>>> 2. User needs a way to choose icon set (if there's a choice)
>>>
>> x:data forms seems like a perfect fit here
>>> 3. Jabber server and web server need to share information
>>>
>> Easiest way for this would be for them both to share a database of
>> presence information with a jabber component keeping it up to date.
>>> 4. Would not be dynamic (that would require an xmpp: URI)
>>>
>>> At the jabber.org domain, #3 is a bit of a pain (the web server and
>>> jabber server are on different machines), but the challenge seems to
>>> be surmountable.
>>>
>>> Other IM systems have this and it's one of those cool features that
>>> end users really like. So what's holding us back? What's needed to
>>> make this happen?
>>>
>> Nothings holding us back this has been available for quite some time
>> in various forms on jabber.
>>
>> Richard
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFEFbO0NF1RSzyt3NURAlbwAJ9rhSwaD893Ilo0PBqhg3oxgMWhjwCfR1de
J3rxkGox7XZ69OjJw4DANcc=
=4/tt
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
Url :
https://www.jabber.org/jdev/attachments/20060313/43e57c25/smim
e-0001.bin
------------------------------
Message: 2
Date: Mon, 13 Mar 2006 10:15:10 -0800 (PST)
From: <ennova2005-jabber at yahoo.com>
Subject: Re: [jdev] web presence
To: Jabber software development list <jdev at jabber.org>
Message-ID: <20060313181510.43728.qmail at web30413.mail.mud.yahoo.com>
Content-Type: text/plain; charset="iso-8859-1"
We have previously developed such a component for an internal project
using the component approach and a database - we used presence bcc to
get all presence updates.
Somethings to keep in mind around freshness of presence information.
When the jabber server restarts - all your existing information in the
DB is stale. You may want to detect this and purge the presence store.
Similar cases arise when there is loss of connectivity between the
component cases. User accounts may get deleted on the IM server and you
may need to synchronize that on your database also.
Over time, I have found that such a presence server capability is best
built "directly" into the IM server with tight integration with the
presence processing and subscriber management modules. This way you
benefit from privacy policies that are available in the same place.
YMMV.
Peter Saint-Andre <stpeter at jabber.org> wrote: -----BEGIN PGP SIGNED
MESSAGE-----
Hash: SHA1
+1, that seems like a sensible approach.
/psa
Peter Millard wrote:
> This is exactly how I would implement this as well.
>
> 1) Have an external component that uses iq:register protocol with
> x-data for picking themes, etc. This component subscribes to the
> user's presence during registration (just like a transport does). Now
> the component has the users presence.
>
> 2) External component pushes presence info into a database (mysql,
psql, etc).
>
> 3) Write a quick PHP applet or something which returns an image based
> on the JID.
>
> We could easily deploy something like this on jabber.org provided the
> DB is psql, and the component is not in Java or Perl (for scalability
> issues). Seems like this would be super easy to write using the
> Twisted Python jabber component stuff.
>
> This approach would also work with any server implementation since the
> component is subscribing to the user's presence.
>
> pgm.
>
> On 3/9/06, Richard Dobson wrote:
>>> It would be good if we had standardized methods for embedding
>>> presence information in web pages. For example, I'd like to be able
>>> to point to the following image file and have it show my presence:
>>>
>>>
>>>
>>> Granted there are challenges here:
>>>
>>> 1. Needs to be opt-in (no presence leaking)
>>>
>> Have it as a contact on the users roster which represents the
>> presence service, if that contact can see the users presence the user
is opting in.
>>> 2. User needs a way to choose icon set (if there's a choice)
>>>
>> x:data forms seems like a perfect fit here
>>> 3. Jabber server and web server need to share information
>>>
>> Easiest way for this would be for them both to share a database of
>> presence information with a jabber component keeping it up to date.
>>> 4. Would not be dynamic (that would require an xmpp: URI)
>>>
>>> At the jabber.org domain, #3 is a bit of a pain (the web server and
>>> jabber server are on different machines), but the challenge seems to
>>> be surmountable.
>>>
>>> Other IM systems have this and it's one of those cool features that
>>> end users really like. So what's holding us back? What's needed to
>>> make this happen?
>>>
>> Nothings holding us back this has been available for quite some time
>> in various forms on jabber.
>>
>> Richard
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFEFbO0NF1RSzyt3NURAlbwAJ9rhSwaD893Ilo0PBqhg3oxgMWhjwCfR1de
J3rxkGox7XZ69OjJw4DANcc=
=4/tt
-----END PGP SIGNATURE-----
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
https://www.jabber.org/jdev/attachments/20060313/794cd523/atta
chment-0001.html
------------------------------
Message: 3
Date: Mon, 13 Mar 2006 11:48:03 -0700
From: Peter Saint-Andre <stpeter at jabber.org>
Subject: Re: [jdev] Resource binding limit(ation)
To: Jabber software development list <jdev at jabber.org>
Message-ID: <4415BE63.9030907 at jabber.org>
Content-Type: text/plain; charset="iso-8859-1"
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Vinod Panicker wrote:
> On 11/24/05, Vinod Panicker <vinod.p at gmail.com> wrote:
>> On 11/24/05, Norman Rasmussen <norman at rasmussen.co.za> wrote:
>>> I think you can by forcing binding to an existing resource, but I'm
>>> not sure it allows you to force an old resource off and bind a new
>>> one.
>> Wont work since even binding to an existing resource would mean that
>> I'm adding one more connected resource (albeit of a same name). What
>> I'm asking is - shouldn't this be treated in the same way we treat
>> server provisioning for allowing/disallowing two resources of the
>> same name to be available?
>>
>>> On 11/24/05, Vinod Panicker <vinod.p at gmail.com> wrote:
>>>> According to RFC 3920 -
>>>>
>>>> o The client is not allowed to bind a resource to the stream
(e.g.,
>>>> because the node or user has reached a limit on the number of
>>>> connected resources allowed).
>>>>
>>>> Wont it make sense if there is some provision to automatically
>>>> logoff the user from a previous resource (based on server
>>>> provisioning) if he's trying to login from a new resource?
>
> No closure on this so I'm assuming that we are not allowing any more
> resources to login once the limit has reached, though it would be
> great to have something that allows the server to logoff an existing
> resource to make way for the new one.
Sure, an implementation could do that if it wants. Nothing in the spec
forbids it and you can implement it if you think it's a cool feature.
Peter
- --
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFEFb5jNF1RSzyt3NURAo6NAKDVcmmaKqEZ5dH+tVCbRUVeglw3CgCdEl86
g7w7wU8LvfAtZHtl9aJzrmI=
=yox4
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
Url :
https://www.jabber.org/jdev/attachments/20060313/168d3073/smim
e-0001.bin
------------------------------
Message: 4
Date: Mon, 13 Mar 2006 14:44:45 -0500
From: "Hal Rottenberg" <halr9000 at gmail.com>
Subject: Re: [jdev] web presence
To: "Jabber software development list" <jdev at jabber.org>
Message-ID:
<b13a36870603131144ie17595ducdbb48db96a0f98d at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On 3/13/06, Peter Saint-Andre <stpeter at jabber.org> wrote:
> +1, that seems like a sensible approach.
>
> /psa
>
> Peter Millard wrote:
> > This is exactly how I would implement this as well.
So let me summarize the current conversation:
- There are several implementations of web presence today
- There are 4 well-known methods
- You can do it with Perl, PHP and other languages right now (code
exists)
- I found FH's component code here:
http://jabberstudio.org/projects/webstatus/project/view.php
- Edgar's website with code was stated earlier in this conversation.
- There may be a couple of closed-source or commercial implementations
out there.
- Jive has a plugin available for their server
Do we need an informational JEP to cover best practicies? Or maybe just
a wiki page on wiki.jabber.org with links to resources? Are there other
actions that people can take to help make this a de-facto feature of
Jabber, just like chatrooms and JUD? As PSA said initially,
"It would be good if we had standardized methods for embedding presence
information in web pages"
Is there anything going on in any other code repos, mailing lists or
forums, something we can hope to use with jabber.org?
--
Psi webmaster (http://psi-im.org)
im:hal at jabber.rocks.cc
http://halr9000.com
------------------------------
_______________________________________________
jdev mailing list
jdev at jabber.org
http://mail.jabber.org/mailman/listinfo/jdev
End of jdev Digest, Vol 26, Issue 25
************************************
More information about the JDev
mailing list