Another aspect of using XMPP for social networking notifications which confuses me is this:
At which JID should I receive these notifications? I don't really want "so and so would like to friend you" and "your friend is now a zombie and ate your brain" messages coming to my iChat, adium, or gaim window. And yet, I don't really want to maintain any more JIDs than I need to. In addition, there's the issue of message capture by different clients. If I *am* logged in via a chat client to the same JID that my DiSo-enabled site is using, will I lose messages if the real-time client is available to receive it but my "social inbox" client has not connected recently? Can using different resources ([EMAIL PROTECTED]/ichat, [EMAIL PROTECTED]/website) help solve this? How widely are resources supported? I hope that some of you in the XMPP world can set me straight... --Steve On Thu, Jun 19, 2008 at 12:05 PM, Steve Ivy <[EMAIL PROTECTED]> wrote: > Hi Peter - welcome to the conversation! > > From my POV, the main goal of building on XMPP is to provide as > near-realtime notifications of social events in this nascient social > framework. And XMPP (and it's various and numerous extensions ;-) ) > provides 90% of those needs. The "last mile" however, is the web view > of that data stream - or, of course, a snapshot of it as it existed > when the request was made. That last mile has been the thorn in the > side of the shared-hosting user. > > I initially started building a wordpress XMPP plugin [1]. It would log > into an XMPP server for a short time, receive events, then pass those > events through a series of callbacks to let other plugins do stuff > with the messages. It's still a model I like, except for the "php page > logging into xmpp server" bit. two problems with that model: > > * It requires the user to setup cron or similar to trigger the code > that periodically connects to the server, and > * It requires the server to be configured to queue messages for the > user if they're not logged in. > > Both of these need to be solved in order for the shared-hosting user > to participate in this real-time network. > > Chris pointed earlier to someone who's created a prototype > xmpp->atompub bridge. That approach sounds to me like a GREAT way to > have new notifications selectively published into a stateless (which > is really the limitation for a shared-hosting user) environment. > WordPress and MovableType (and quite a few others) support AtomPub so > it makes a lot of sense to me. > > At the beginning, I took the position that any DiSo code should run > under that stateless, shared-hosting limitation. As I look at it now, > though, I think that having DiSo plugins for stateful systems like > jabber servers makes all the sense in the world. If that wordpress > user wants access to these features, they just need to have access to > a provider that offers (in this case) a compatible xmpp service. > > Ok, that was a bit long-winded, but if we can harness the power of a > real-time system like XMPP without losing the participation of the > small/self-hosted users, then things reach a new level of WIN. > > --Steve > > [1] > http://code.google.com/p/diso/source/browse/wordpress/wp-xmpp/trunk/xmpp-client.php > > On Thu, Jun 19, 2008 at 11:47 AM, Peter Saint-Andre <[EMAIL PROTECTED]> wrote: >> On 06/18/2008 12:58 PM, Chris Messina wrote: >> >>> I see no reason not to use ATOM or XMPP for this, except that XMPP doesn't >>> work well with today's shared hosting environments. >> >> Says who? DreamHost, GMX, and other shared hosting companies offer XMPP >> support. I don't see the problem. >> >> Peter >> >> -- >> Peter Saint-Andre >> https://stpeter.im/ >> >> > > > > -- > Steve Ivy > http://redmonk.net // http://diso-project.org > This email is: [ ] bloggable [x] ask first [ ] private > -- Steve Ivy http://redmonk.net // http://diso-project.org This email is: [ ] bloggable [x] ask first [ ] private
