> 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?
This is *exactly* what I found in my prototype. If you have your test client and Google Talk logged into the same account you get a message to them both. If you are offline and then you online, you get the message to the one you log with first. I had considered whether you need separate id's - [EMAIL PROTECTED] versus [EMAIL PROTECTED] but that's a pain. As an extension to this idea, say you are in a "room" as per FriendFeed (or Twitter hastags) and you want to receive the generic messages but not have to be a friend of everyone (you are a friend of the room) - how best to support this? (a brief look seems to indicate that it *can* be done as part of the infrastructure, I'm just now sure). Maybe this is what you are saying in your first point. steven http://livz.org -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Ivy Sent: 19 June 2008 20:20 To: [EMAIL PROTECTED]; [email protected] Subject: [diso-project] Re: [Social] [diso-project] Re: OpenMicroBlogging 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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "DiSo Project" group. To post to this group, send email to [EMAIL PROTECTED] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/diso-project?hl=en -~----------~----~----~----~------~----~------~--~---
