[Standards] Microblogging structure
justin-keyword-jabber.093179 at affinix.com
Mon Nov 29 19:02:54 UTC 2010
On Monday 29 November 2010 03:40:09 Florent Le Coz wrote:
> On 11/27/2010 02:23 PM, Thomas Baquet wrote:
> > Hi,
> > I was reading the xep-0277 (Microblogging over XMPP), when I was
> > asking myself if the structure used for reply is really interesting:
> > if Mr. A has subscribed to my µblog node but not the Mr. B's one, and
> > if Mr. B answered to me, it can be interesting for Mr. A to access to
> > Mr. B's answer. In this case, the system used by the xep is not
> > efficient: the reply notification will only be sent to me, not to Mr. A.
> > Then, why not making something like a notify-node where a new entry is
> > added when Mr. B post is own answer on his node. The entry added to my
> > node will just be a reference to Mr B's answer. Like this, he keeps
> > control of his published data, but everybody will be notified by this.
> > This system should be generalized for other kind of publications, like
> > blog articles, forums, etc.
> The problem you're pointing here is very similar to what I noted
> earlier, see this previous thread:
> See also the next posts, with responses to this problem.
> By the way, Dave, did you come up with a solution? Would it help you if
> I (and others) wrote a modified version of 0277. Because things didn't
> move for a while, and I would appreciate that they did.
This kind of stuff is also interesting to me, and one of the problems I've run
into is the need to reliably synchronize actions to two locations. For
example, if you leave a comment on a post, then data about the comment should
ideally exist at both:
1) the service of the post being replied to (so that people viewing the post
know how to also view replies by anyone)
2) the service of the author making the reply (so that people viewing a list
of actions made by the author can see all of his replies around the world,
including references back to the parent posts)
In playing around with protocol ideas to handle this, I believe an ideal flow
is one whereby the user submits data to only one of these services and somehow
the services are chained such that service the user submitted to will in turn
submit to the other service. This way we avoid the complexities of having a
user try to perform an atomic submission to two locations.
More information about the Standards