Re: [Standards] Microblogging structure
On Mon Nov 29 11:40:09 2010, Florent Le Coz wrote: 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. They are moving, but slowly. The Buddycloud people are moving toward defining their Channels, with the intent that anyone would be able to make not only personal Microblogs, but general "topic" channels as well. These look and smell much like Facebook's Wall - that is, people post directly to your channel - but there's a bunch of us tossing about ideas on this one. One suggestion was to have both the Channel, as it exists now, and other streams for referencing [foreign] channel activity the user wanted people to know about, and marking favourites, for instance. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] Microblogging structure
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. > > Hi, > > The problem you're pointing here is very similar to what I noted > earlier, see this previous thread: > http://mail.jabber.org/pipermail/standards/2010-September/023817.html > 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. -Justin
[Standards] NEW: XEP-0289 (Federated MUC for Constrained Environments)
Version 0.1 of XEP-0289 (Federated MUC for Constrained Environments) has been released. Abstract: This document provides a protocol for reducing the bandwidth cost of local users contributing to a remote MUC over a constrained link through local proxying of the MUC room. Changelog: Initial published version. (psa) URL: http://xmpp.org/extensions/xep-0289.html
[Standards] ACTIVE: XEP-0201 (Best Practices for Message Threads)
Version 1.0 of XEP-0201 (Best Practices for Message Threads) has been released. Abstract: This specification defines recommended handling of XMPP message threads. Changelog: Per a vote of the XMPP Council, advanced specification to Active. (psa) URL: http://xmpp.org/extensions/xep-0201.html
Re: [Standards] Microblogging structure
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. Hi, The problem you're pointing here is very similar to what I noted earlier, see this previous thread: http://mail.jabber.org/pipermail/standards/2010-September/023817.html 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. -- Florent
