I have said this to Steve privately, and I will now say it publicly:
reinventing messaging protocols over HTTP is a *bad* idea. We have
protocols (more than one, two very popular ones), *open* *standard*
protocols (yes, I'm looking square at SMTP and XMPP - as well as NNTP,
which is less applicable) that do messaging *well* *really well* they
were, well, *built for it*. They have faced the problems and improved
to solve them. They stand the test of time, *do* the job, and are
*widely* implemented. Unless there is a use case that one of the
existing standards cannot meet (which I doubt more each time I
consider this), I see no reason to invent anything, only to build
tools to use what we have.
Furthermore, reinventing content pushing over HTTP is a *bad* idea.
There are several *open* and *implemented* (although less widely than
messaging protocols) standards for pushing content *even specifically
post or blog-type content* over HTTP. XML-RPC and AtomPub, to name
two.
(Yes, this is a variation on my "please don't invent anything" rant.)
--
- Stephen Paul Weber (Singpolyma)
Web: http://singpolyma.net/
Twitter: http://twitter.com/singpolyma
IM: singp...@gmail.com
With the intention of at least being controversial here let me put a counter point.
Some of the “infrastructure” technologies on the web aren’t particularly simple and often come with an unwanted about of baggage and effort (as well as being platform specific). I remember looking at XMPP for something I was working on and finding it far more complex (I use C# and it was hard to find much that was useful at the time) than I needed and furthermore the effort required to tie it in was outwith “just me”. You just need to look here [1] to see how it easy to be overwhelmed. The RFC for XMPP Core alone is 90 pages.
So the platform you mention and we all love got there by designing a vision of what people wanted to see rather than from a technology perspective (sure it came back to bite a bit but they’re still doing ok). You can also consider SGML did a lot of what we needed to do before Xml came along, but even Xml has been diluted to numerous formats and structures (we had Xml then RSS, JSON and so on). I remember RSS 0.91 and thinking at the time – “big deal, it’s just Xml”.
So my argument is that services such as microblogging are actually pretty easy to understand and use other (relatively) small protocols such as OAuth, YADIS and so on – basically you can read it in one page or so.
The crux of my argument (from a developer perspective) is that i Iike simple interface based stuff that can be joined together to create something complex. You implement how you see fit (one guy and his dog or an enterprise) so long as you agree to the contracts!
Then again, perhaps someone knows a way of using XMPP simply J Remember, I’m not necessarily saying an XMPP solution wouldn’t be technically better, just perhaps, to be controversial, harder to gain traction.
Regards,
Steven
Yes, I agree that this is something that we want. Although the use
case here might be more that you want to publish a message in general
and the other party wants to be sure they receive it.
> So if I self-identify as http://twitter.com/factoryjoe and I want to send a
> message to http://twitter.com/redmonk, if on that endpoint is a discovery
> document that suggests where to send messages and how to sign them so that
> the messages will be received and not rejected outright, I think we're
> getting somewhere.
I will be shot down, but will suggest that hCard provides us with
this. (Possibly spidering rel=me), hCard can encapsulate the
addresses/endpoints of users on at least two of the aforementioned
protocols (XMPP and SMTP).
> except that XMPP doesn't
> work well with today's shared hosting environments.
Not entirely true. Running your own XMPP *bot* doesn't play well, but
having an XMPP account at your domain is allowed by multiple shared
hosting providers (Dreamhost as an example) and if you have DNS
control over your domain name you can also use the Google Talk
component of Google Apps for your domain to get an XMPP address at
your domain. Those with no domains can just get an address with any
number of existing servers (many already have one with Google or
Livejournal). Also, sending messages over XMPP is getting easier and
easier from shared hosting, with increasingly good Jabber support in
Ruby, Python, and PHP libraries. Just *receiving* those messages in a
*script* is less easy. Certainly not insurmountable if it is
required, but I'm not sure it is.
> discovery to point to an XMPP endpoint and then offer a fallback ATOM
> endpoint in the case that XMPP would fail?
Supporting multiple protocols is often a good idea :)
> My question is given the simplicity of microblogging, assuming we get an activity stream spec/solution figured out,
> wouldn't it implicitly solve the "open" microblogging need? Given that a microblogging "action" is the same as its
> "notification", it looks to me to be a specialized subset of activity streams.
Agreed. This is the subscription model and not a push model, but it's
what is used on the open web for a lot of things today (like
actionstream aggregators, etc).
>Some of the "infrastructure" technologies on the web aren't particularly simple and often come
> with an unwanted about of baggage and effort
That's why I love library authors like @nathan.fritzclan.com, they
abstract the complexity away into a few classes/function calls.
My question is given the simplicity of microblogging, assuming we get an activity stream spec/solution figured out, wouldn’t it implicitly solve the “open” microblogging need? Given that a microblogging “action” is the same as its “notification”, it looks to me to be a specialized subset of activity streams.
Agreed.
> That said, I love what
> Evan is trying to do in terms of actually shipping a way that this stuff
> could work.
++implementation
--new protocol invention
Presume that I have a URL of my own, given a recipient URL, I want to be able to send a message "at it" and have it be received on the other end, and be routed properly, based on the recipient's rules. As the sender, I just want to be able to send a message and know that the recipient should receive it.This parallels having a "from" email address and sending it "to" a recipient email address. But in this case we're replacing email as the identifier with a URL.
So if I self-identify as http://twitter.com/factoryjoe and I want to send a message to http://twitter.com/redmonk, if on that endpoint is a discovery document that suggests where to send messages and how to sign them so that the messages will be received and not rejected outright, I think we're getting somewhere.
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. Perhaps we use XRDS discovery to point to an XMPP endpoint and then offer a fallback ATOM endpoint in the case that XMPP would fail?
You know that I'm against inventing unnecessarily -- which is why I pointed out this microblogging effort. It might not be the way to do it, but it gives us an example of someone's thinking that's actually been implemented and gives us something to build against.
Chris,
I can't see any reason why an XRDS file with a link to the appropriate JID would NOT be the correct way to implement this. Is there something I'm missing?
bob wyman
For what it’s worth – if you wish to hack a demo I have set up an XMPP Openfire server. It was really to investigate where things are since my last look. To develop a server – or even a client - there is still a lot of work in XMPP (open source *servers other than Openfire were hard to find) which is my only worry.
However, as a packaged solution it was pretty easy. My ISP doesn’t support the default port so I had to use an alternative but managed to connect via Exodus ok and send some messages. I found you can create a new user directly through most clients which is neat.
1. Just enter your desired jabber id in the format user...@openid.org … I am web...@openid.org
2. Choose a password
3. In the connection, enter the host as “openid.org”
4. Change the default port to 5901
5. That’s it.
In view of how easy this was and the number of open source clients available, I can only imagine that this kinds of infrastructure to be a great building block.
My *only* concern is that if you want to run your own server there are a lot of commercial clauses I saw and writing your own is certainly not trivial (unlike writing some simple sender/listener as defined in the openmicroblogging.org contract).
If someone wishes to use this to hack some xrds and do some testing I’d be glad to help out (other than tomorrow morn when I am at a funeral).
Regards,
Steven
Apologies to those that mailed me – I logged off the remote server and it seemed to close down the service. Ok now.
Thinking about it, I like the idea of an xrds giving you a pointer to the “IM” user service, just not convinced (in simpler cases such as openmicroblogging) it should always be a jabber id.
steven
From: Steven
Livingstone-Perez [mailto:web...@hotmail.com]
Sent: 19 June 2008 17:25
To: 'diso-p...@googlegroups.com'; 'XMPP and Social Networking, Two
Great Tastes That Taste Great Together!'
Subject: RE: [diso-project] Re: [Social] [diso-project] Re:
OpenMicroBlogging
For what it’s worth – if you wish to hack a demo I have set up an XMPP Openfire server. It was really to investigate where things are since my last look. To develop a server – or even a client - there is still a lot of work in XMPP (open source *servers other than Openfire were hard to find) which is my only worry.
However, as a packaged solution it was pretty easy. My ISP doesn’t support the default port so I had to use an alternative but managed to connect via Exodus ok and send some messages. I found you can create a new user directly through most clients which is neat.
1. Just enter your desired jabber id in the format user...@openid.org … I am web...@openid.org
2. Choose a password
3. In the connection, enter the host as “openid.org”
4. Change the default port to 5901
5. That’s it.
In view of how easy this was and the number of open source clients available, I can only imagine that this kinds of infrastructure to be a great building block.
My *only* concern is that if you want to run your own server there are a lot of commercial clauses I saw and writing your own is certainly not trivial (unlike writing some simple sender/listener as defined in the openmicroblogging.org contract).
If someone wishes to use this to hack some xrds and do some testing I’d be glad to help out (other than tomorrow morn when I am at a funeral).
Regards,
Steven
From:
diso-p...@googlegroups.com [mailto:diso-p...@googlegroups.com] On
Behalf Of Chris Messina
Sent: 19 June 2008 14:21
To: XMPP and Social Networking, Two Great Tastes That Taste Great
Together!; diso-p...@googlegroups.com
Subject: [diso-project] Re: [Social] [diso-project] Re:
OpenMicroBlogging
Perhaps we just need to code up a demo using this approach and probe the challenge moot: I'd be thrilled if the building blocks we already have solve this problem and be put in place immediately!
> 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/
> I appreciate the effort, but frankly, Twitter exports all the microblogging
> information using a combination of already-available standards; Atom (maybe
> hAtom?), hCard, etc. Why on earth would we seek to re-implement Atom when a
> simpler approach satisfies the needs?
Agreed -- let's see how far we can get with widely-deployed technologies
and only then try to fill any remaining gaps.
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
--
Steve Ivy
http://redmonk.net // http://diso-project.org
This email is: [ ] bloggable [x] ask first [ ] private
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 (my-...@server.org/ichat,
my-...@server.org/website) help solve this? How widely are resources
supported?
I hope that some of you in the XMPP world can set me straight...
--Steve
How is contacting the page owner / creator less "direct" than finding an
alternative representation of the content? If the web is to be truly
social then ISTM that it's completely appropriate to provide links to
content creators, discussion forums, microblogging feeds, and anything
else of interest.
> Thus, it seems reasonable to
> use a mechanism which is explicitly intended to store links to persons or
> things with identity -- i.e. the XRDS file.
>
> Today, there aren't many things that get put in XRDS files. The result is
> that XRDS files often seem over designed for the limited purpose of
> providing links to OpenID services, etc. However, I think we'll find in the
> future that users will have a need to associate a broad set of linked
> resources to their identities. As this set of commonly linked resources
> grows, it will become less and less reasonable to stuff them all into HTML
> embedded <link rel>s. It should also be noted that it is quite likely that
> in many applications, XRDS files won't actually be maintained as static
> files on disk. They will, in fact, be generated on-demand and as a result
> will be able to accommodate potentially changing data. (my XRDS file might
> contain a link to the resource that describes my current location...)
> Forcing links to be stored in HTML would have the effect of discouraging the
> use of dynamic sets of links and, even if implemented via various templating
> systems, the use of dynamically changing links in HTML files would tend to
> make a mess of caching schemes -- even though the changes are not related to
> the HTML content itself.
>
> Use <link rel> for what it was intended to be used: Links to resources which
> are related to the containing HTML page. Use XRDS files for links that
> relate to things which have identity.
Says who? Can't a link point to any URI, not just a web page? I don't
see any such restriction in the HTML 4.0 spec.
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 - web...@gmail.com versus web...@social.gmail.com 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: diso-p...@googlegroups.com [mailto:diso-p...@googlegroups.com] On Behalf Of Steve Ivy
Sent: 19 June 2008 20:20
To: diso-p...@googlegroups.com; soc...@xmpp.org
Subject: [diso-project] Re: [Social] [diso-project] Re: OpenMicroBlogging
I've only skimmed through the brainstorming doc and apologies if this
has already been discussed before and I've not found the prior
discussions but ...
We already have a discovery mechanism in place for web and (especially)
mail endpoints - it's DNS and it's well understood and battle proven to
work.
It's extensible too - see SPF and also RFCs 1712 and 1876 which describe
how to provide location information in your zone file.
So instead of
<!-- Messaging 1.0 Endpoint Definition -->
<Service priority="10">
<Type>http://xrdstype.net/messaging/1.0/server</Type>
<URI simple:httpMethod="GET">http://endpoint.mysocialinbox.com</URI>
<LocalID>http://myopenid.example.com</LocalID>
</Service>
why not something like (completely off the top of my head and stolen
liberally from SPF)
example.org. IN TXT "v=messaging1.0 \
server=http://endpoint.mysocialinbox.com \
local-id=http://myopenid.example.com"
or
example.org. MSG endpoint.mysocialinbox.com \
local-id=http://myopenid.example.com
Or, to put it another way, why reinvent everything again over HTTP. Why
have your messaging endpoint rely on your web server (unless of course
the goal is to reinvent messaging over HTTP which is a whole other
argument)?
Again - sorry if I've missed this discussion already.
Simon
I think XMPP is also a lot to learn for your typical Drupal/WordPress
coder, but if we do some heavy lifting and get the abstractions and
libraries done right, all those concerns melt away.
Where should we go next?
Sent by 1G iPhone.
What does having a JID on each service really do for the user, if the
idea is to have notifications all come to one or a few places?
(notifications to the web/inbox, im to the im client)?
--
Steve Ivy
http://redmonk.net // http://diso-project.org
--
> http://www.cestari.info/2008/6/19/atom-pubsub-module-for-ejabberd
Re-iterating my previous statement, perhaps we should approach the
author about filling out the functionality some and supporting it in
some way?
--Steve
On Thu, Jun 19, 2008 at 2:27 PM, Jean-Marc Liotier <j...@liotier.org> wrote:
> Also sprach Steve Ivy [Thu, Jun 19, 2008 at 12:20:23PM -0700] :
>>
>> 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.
>
> That is what publish-subscribe is about : you only susbscribe to the
> streams that you want to receive notification from.
>
> And then not all messages need to be rendered as chat on the client
> side. For now most XMPP clients are in fact chat clients - and the
> current user experience of notifications through XMPP is therefore the
> reception of a message from a "contact". But those notifications could
> also be rendered as a news stream the way we render Atom or RSS, or it
> could be a ticker tape, or a tray notification popup or whatever you
> want to develop your client as...
>
>> 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?
>
> When server side history becomes widespread (probably through
> implementations of XEP-0136) this problem will cease to exist just as
> all my mail clients see the same messages on my IMAP server.
Granted, that in itself is awesome.
However, ideally a site could subscribe to the node and have new posts
be pushed put via atompub to the site. This would require some kind of
authentication, which does complicate things. :(
Sylvain, this is great work, and exactly what we've been discussing
the last day or so - how to get XMPP and web services playing
together. It looks like you've got XMPP packets being pushed *out* to
an AtomPub API, which is a big deal!
Ok, discuss!
--Steve
> All,
> I had started coding around that topic a few weeks ago but got slowed
> down more than I expected. Anywy a first few gradual steps for those
> interested.
> http://www.defuze.org/archives/20-Microblogging-with-XMPP-and-AtomPub.-Dumping-code..html
> - Sylvain
> PS: Sorry for cross posting.
--
Jean-Mark -
Excellent! This scenario is in fact what pushed me to look at XMPP in the
first place (I had been writing my own pubsub system at first due to
confusing commercial clauses in many of the XMPP servers I first looked at).
Do you (or anyone else out there) have pointers to applications that do this
kind of thing with XMPP?
Regards,
Steven
http://livz.org
-----Original Message-----
From: social-...@xmpp.org [mailto:social-...@xmpp.org] On Behalf Of
Jean-Marc Liotier
Sent: 19 June 2008 22:27
To: XMPP and Social Networking, Two Great Tastes That Taste Great Together!
Cc: diso-p...@googlegroups.com
Subject: Re: [Social] [diso-project] Re: [diso-project] Re:
OpenMicroBlogging
Also sprach Steve Ivy [Thu, Jun 19, 2008 at 12:20:23PM -0700] :
>
> 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.
That is what publish-subscribe is about : you only susbscribe to the
streams that you want to receive notification from.
And then not all messages need to be rendered as chat on the client
side. For now most XMPP clients are in fact chat clients - and the
current user experience of notifications through XMPP is therefore the
reception of a message from a "contact". But those notifications could
also be rendered as a news stream the way we render Atom or RSS, or it
could be a ticker tape, or a tray notification popup or whatever you
want to develop your client as...
> 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?
When server side history becomes widespread (probably through
Not if it's the site's server. If I run my own server to do this, a
fakecronjob in WP to harvest RSS (or in this case, ATOM) is just as
good as / better than the server hitting me with every message (for
web server scaling/performance, etc) - this more from my exp at
AideRSS than on share hosting, but I think it applies equally in both
places.
Not if it's the site's server. If I run my own server to do this, a
And is only useful for discovery on hostnames, not specific URIs.
I actually did some work in using with Jabber PEP (sub part of PubSub spec)
to get OpenMicroblogging style posts (and Twitter style) using simple Atom
entry fragments - sending Atom feeds as well as receiving them. That post
mentions PubSub, but not PEP explicitly so not sure if it uses it.
Doing more on it just now, but it works really nicely and is well supported
by Openfire etc. Some thoughts around how to get twitter or jaiku style web
views of the notifications as they aren't explicitly "friends" but there are
ways around it.
I hadn't seen your link so that is very useful!
Cheers,
Steven
http://livz.org
-----Original Message-----
From: social-...@xmpp.org [mailto:social-...@xmpp.org] On Behalf Of
Pedro Melo
Sent: 23 June 2008 14:01
To: XMPP and Social Networking, Two Great Tastes That Taste Great Together!
Cc: diso-p...@googlegroups.com
Subject: Re: [Social] [diso-project] Re: [diso-project] Re:
OpenMicroBlogging
Hi,
On Jun 20, 2008, at 8:32 AM, Steven Livingstone-Perez wrote:
>> But those notifications could also be rendered as a news stream
>> the way we
> render Atom or >RSS, or it could be a ticker tape, or a tray
> notification
>
> Jean-Mark -
> Excellent! This scenario is in fact what pushed me to look at XMPP
> in the
> first place (I had been writing my own pubsub system at first due to
> confusing commercial clauses in many of the XMPP servers I first
> looked at).
>
> Do you (or anyone else out there) have pointers to applications
> that do this
> kind of thing with XMPP?
The currently-defunct Twitter IM gateway used to send a pretty cool
atom entry of each notification.
I couldn't find a URL describing a message. Its mentioned briefly here:
http://groups.google.com/group/twitter-development-talk/web/jabber-
pubsub
Best regards,
--
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: me...@simplicidade.org
Use XMPP!
Well, and again, I'm not trying to stir here, just trying to get my head
around the problem space so sorry if I sound combative - I wasn't
proposing a DNS entry for every endpoint but more like email (which we
know scales).
So, just like email you'd define a messaging end point and then to get
messages (say, updates to the page) from that you'd subscribe to the
XMPP stream (or similar) to that page.
So, say for example from Typepad (since I work for Six Apart) and the
domain 'example.typepad.com' - I look up the DNS record for that and get
messaging.example.typepad.com as the endpoint. Then I subscribe to
/@messaging.example.typepad.com
to get every update for the whole domain.
Or
/post/@messaging.example.typepad.com
to get a message for every post.
Or
/post/some_po...@messaging.example.typepad.com
to get every update for a given post.
Or
/pro...@messaging.example.typepad.com
to get a message everytime profiles change.
Or
/profiles/si...@messaging.example.typepad.com
to get everytime my particular profile changes. Or in your example
/users/facto...@messaging.foocamp.ning.com
Obviously that's all a bit rough and ready and I'm kind of thinking
aloud whilst I write but we can show that autocreating jabber-ids works
because we did it for every single LiveJournal user, and this fits in
with existing infrastructure rather than going the "invent new XML
standard" route.
Again, sorry if I'm missing the point here.
Simon
Yes – I can see why that is useful. A main difference is the with PEP there is some built in security (certainly in the Jabber servers I have used) that allows you to restrict what someone can do with the endpoint (e.g. you are free to create new nodes within your account) … with general PubSub I guess you manage this yourself.
I actually think both are useful under different scenarios.
Let me frame the challenge/opportunity this way:Presume that I have a URL of my own, given a recipient URL, I want to be able to send a message "at it" and have it be received on the other end, and be routed properly, based on the recipient's rules. As the sender, I just want to be able to send a message and know that the recipient should receive it.This parallels having a "from" email address and sending it "to" a recipient email address. But in this case we're replacing email as the identifier with a URL.
So if I self-identify as http://twitter.com/factoryjoe and I want to send a message to http://twitter.com/redmonk, if on that endpoint is a discovery document that suggests where to send messages and how to sign them so that the messages will be received and not rejected outright, I think we're getting somewhere.
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. Perhaps we use XRDS discovery to point to an XMPP endpoint and then offer a fallback ATOM endpoint in the case that XMPP would fail?You know that I'm against inventing unnecessarily -- which is why I pointed out this microblogging effort. It might not be the way to do it, but it gives us an example of someone's thinking that's actually been implemented and gives us something to build against.Chris
On Wed, Jun 18, 2008 at 11:33 AM, Eran Hammer-Lahav <er...@hueniverse.com> wrote:
My question is given the simplicity of microblogging, assuming we get an activity stream spec/solution figured out, wouldn't it implicitly solve the "open" microblogging need? Given that a microblogging "action" is the same as its "notification", it looks to me to be a specialized subset of activity streams.
EHL
> Is this something we could/should implement? How could we make it more
> "DiSo" friendly? (Sorry I need to read it over but haven't had a chance
> yet).
I have said this to Steve privately, and I will now say it publicly:
reinventing messaging protocols over HTTP is a *bad* idea. We have
protocols (more than one, two very popular ones), *open* *standard*
protocols (yes, I'm looking square at SMTP and XMPP - as well as NNTP,
which is less applicable) that do messaging *well* *really well* they
were, well, *built for it*. They have faced the problems and improved
to solve them. They stand the test of time, *do* the job, and are
*widely* implemented. Unless there is a use case that one of the
existing standards cannot meet (which I doubt more each time I
consider this), I see no reason to invent anything, only to build
tools to use what we have.
Furthermore, reinventing content pushing over HTTP is a *bad* idea.
There are several *open* and *implemented* (although less widely than
messaging protocols) standards for pushing content *even specifically
post or blog-type content* over HTTP. XML-RPC and AtomPub, to name
two.
(Yes, this is a variation on my "please don't invent anything" rant.)
--
- Stephen Paul Weber (Singpolyma)
Web: http://singpolyma.net/
Twitter: http://twitter.com/singpolyma
IM: singp...@gmail.com
--Chris MessinaThis email is: [ ] bloggable [X] ask first [ ] private
Citizen-Participant &
Open Source Advocate-at-Large
factoryjoe.com # diso-project.org
citizenagency.com # vidoop.com
That statement from Roy is left completely unexplained in his own email which goes on and on about DNS. I would welcome an actual explanation of this extremely non-obvious statement about http URI and HTTP protocol not having to be bound together…
EHL
<br