It's my understanding of the XEP process that we standardise ways of doing something so that many clients and servers can interoperate.
And for machine to machine services this is easy: machines do as we say and interoperate as we say. It's a predictable environment. Social is not easy and neither are user and groups of users predictable. Additionally, social services built on XMPP will have different business logic and be built into different applications in different ways. Getting this business-logic right will depend on the problem being solved. That's why I like XEP-0277; it says all one can really say about social (summary of XEP-0277: use atom for posts and post to a pub-sub like node). We all want interoperation between services. Social is different for different products: what works for one kind of use case will not work for someone else: some people think it should be roster based with groups like Google circles. Others want it decoupled from the roster. Some people want to add code to XMPP servers, others build pub-sub solutions. Some services have a single poster model, others are more like MUC with many posters. To help make this conversation go forward we need a solid description of what is being offered to the user. These are the questions we need to answer before we try to work out a spec(s): * the target user (hint: my parents won't be twiddling roster groups) * define the use case * how does it work? what happens when... (this is the social part) * clearly define the publishing and following models I am extremely doubtful that this process leads to a one-size-fits-all answer. And it would be a rather mediocre mishmash of kludges. I think a far more realistic result will be a couple of types of social services. Off the top of my head: * microblogging to pep nodes * twitter-like service * buddycloud-like service Each service (and hopefully spec) will relevant to a particular way of interacting and designed for a type of use case. It's really important that we avoid a rush to standardise that results in something mediocre and end up with the MySpace of the XMPP world: dropped after 2 years and filled with spam. XMPP gives us a huge advantage when building social services: its native federation and its built-in support for remote user-ids are awesome. Let's build awesome services for our users based off specs relevant for a particular use case. S. On 18/08/2011 16:47, Goffi wrote: > Le Jeudi 18 Août 2011 20:40:05, Sergey Dobrov a écrit : >> It's a bad idea to append the number to the namespace since it reserved >> for different revisions of XEP and not for your purpose. Again, I think >> that this should be solved by some privacy lists extension since your >> decision again restricted. > As I said before, it just a Q&D hack for testing purpose, I know it's not a > good solution. I would rather use privacy lists or whatever if we could have > a > per-item access management with it. > >>> If I have to poll this by myself at client side, I'll have to send X IQ >>> stanza for my X contacts, and flood the server. >> Client should cache data. You will flood anyway the only difference is >> who will flood: client or server. > In all cases the client will need the data, and it's better to send one > request to server, that X request for X contacts. > Actually I think about something similar to Extended Stanza Adressing > (http://xmpp.org/extensions/xep-0033.html), but to get several pubsub nodes > at > once. > > >>> I ask last items presence to not have to poll individually all my >>> contacts roster. On some blue centralised services, it's common to have >>> 100+ contacts, should I poll all of them each time I log-in ? >> No, Pubsub node can send you an event when you came online with the >> serial for it's journal so you can decide to ask the node for new items. > Oki, that looks like a nice solution, once again, waiting an answer from > pubsub people. > -- Simon Tennant mobile: +49 17 8545 0880 office: +49 89 4209 55854 office: +44 20 7043 6756 xmpp: [email protected] build your own open and federated social network - http://open.buddycloud.com
