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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, March 14, 2006 1:15 AM To: [email protected] Subject: jdev Digest, Vol 26, Issue 25 Send jdev mailing list submissions to [email protected] 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 [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] 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 ([EMAIL PROTECTED]) 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 <[EMAIL PROTECTED]> Subject: Re: [jdev] web presence To: Jabber software development list <[email protected]> Message-ID: <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 : http://mail.jabber.org/pipermail/jdev/attachments/20060313/43e57c25/smim e-0001.bin ------------------------------ Message: 2 Date: Mon, 13 Mar 2006 10:15:10 -0800 (PST) From: <[EMAIL PROTECTED]> Subject: Re: [jdev] web presence To: Jabber software development list <[email protected]> Message-ID: <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: http://mail.jabber.org/pipermail/jdev/attachments/20060313/794cd523/atta chment-0001.html ------------------------------ Message: 3 Date: Mon, 13 Mar 2006 11:48:03 -0700 From: Peter Saint-Andre <[EMAIL PROTECTED]> Subject: Re: [jdev] Resource binding limit(ation) To: Jabber software development list <[email protected]> Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="iso-8859-1" -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Vinod Panicker wrote: > On 11/24/05, Vinod Panicker <[EMAIL PROTECTED]> wrote: >> On 11/24/05, Norman Rasmussen <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 : http://mail.jabber.org/pipermail/jdev/attachments/20060313/168d3073/smim e-0001.bin ------------------------------ Message: 4 Date: Mon, 13 Mar 2006 14:44:45 -0500 From: "Hal Rottenberg" <[EMAIL PROTECTED]> Subject: Re: [jdev] web presence To: "Jabber software development list" <[email protected]> Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=ISO-8859-1 On 3/13/06, Peter Saint-Andre <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] http://halr9000.com ------------------------------ _______________________________________________ jdev mailing list [email protected] http://mail.jabber.org/mailman/listinfo/jdev End of jdev Digest, Vol 26, Issue 25 ************************************
