On 08/18/2011 08:09 PM, Goffi wrote: > Le Jeudi 18 Août 2011 19:29:21, Sergey Dobrov a écrit : >>> first, here are my main needs for microblogging: >>> >>> - the possibility to have several nodes with different access models, >>> and for a user to subscribe to them automatically >> >> Could you give some example usecases for that? Since I don't really >> understand how you see it possible. > > Well, in my quick and dirty implementation (that I have made mainly to work > on > the frontend), I have several node: urn:xmpp:microblog:0 for the main > microblog node, open access, that everybody can read, even people without > XMPP > account from the website. > > Then I have many other nodes: urn:xmpp:microblog:1, urn:xmpp:microblog:2, ... > Each node has a different access (roster-access "familly", roster-access > "friends"), and I have an other private node (with a whitelist access for > only > the published) which keep a map between my roster-group and the node, so only > the published know that "urn:xmpp:microblog:1" is linked with "familly" > roster > group. Thanks to this map, I can publish to the good node when needed. > > My contacts have a notification because they have discovery feature for > urn:xmpp:microblog:1+notify, urn:xmpp:microblog:2+notify, ..., > urn:xmpp:microblog:big_enough_number+notify (BTW, it would be nice to have > some wildcard charactere like urn:xmpp:microblog:*+notify), and thanks to > access model, then just have notifications if they are in the good group. > > This implementation is a dirty hack, but it works at least for testing > purpose. It would be actually not that bad if I could ask the server all the > items (or the last x ones) that I could access from a given jid. > > You can try it at www.libervia.org (very old interface, a new one is on its > way), but you'll have to create several accounts and play with roster to test > it. > 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.
> >> >>> - the possibility to pull all items of severals peoples (e.g. a roster >>> group) at once >> >> That impossible since these users can be served on different hosts. So >> you should to ask users separately. I don't think that this is too >> ambiguous because it will be needed only once and then you will receive >> events immediately. > > I know that of course, but I think it's server job. A server can host many of > my contacts nodes, so it can at least return the ones it is hosting, and then > ask to other servers the informations it is lacking. At client side, that > mean > just on IQ get stanza, then having the result, which can be huge so maybe > splitted in several stanza. > > 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. > > >>> - push notification when a contact is connected >> >> Presence?? :)) > > Yes this point is already managed in xep-0277, I just mentionned it cause > it's > a must-have. > > >> >>> - the ability to get missed items between the last time a contact was >>> disconnected and the time it reconnect >> >> I already proposed the solution for that but nobody reacted: >> http://mail.jabber.org/pipermail/standards/2011-June/024597.html > > Yes I know, so I hope this time there will be more feedback > >>> The current XEP is based on PEP, and has IMHO many issues: >>> >>> - if you connect with +notify, you have all notifications from all you >>> items, without the ability to filter (e.g. from only on group). >> >> I think that this issue can be solved with an extension for the privacy >> lists. > > I agree > >>> - if somebody published an item 6 months ago, and nothing since, you'll >>> still have it in your notifications. OK you can filter this at client >>> side, but it would be nice to have a date-based filtering way. >> >> Why? I configure the node that it doesn't send last items when presence >> came and this is quite ok. > > 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. >>> - maybe the most important: there is no way to know how many items you >>> have missed neither to get them. Once again, a date-based retrieving >>> way would be a nice addition >> >> Once again: http://mail.jabber.org/pipermail/standards/2011-June/024597.html > > Hope to have feedback from pubsub specialists > Me too :) > >>> - there is no way to retrieve the x last items for x contacts. I'd like >>> to be able to ask to a server « all the post since 1 week from all my >>> contacts in roster-group "friends" ». >> >> You are forget about decentralization again. Again, why is this needed >> if you receive the events IMMEDIATELY? > > Because I'm not always online. For the decentralized issue, see my answer > above. > Again, you will receive serial numbers for the pubsub journal and you can retrieve all the data to make your cache up to date without overhead. That's my decision, maybe some better exists. > >> [SNIP] >>> Furthermore, there is this email from Sergey Dobrov that has not any >>> answer: >>> http://mail.jabber.org/pipermail/standards/2011-June/024618.html . It's >>> a pity 'cause there are many interesting remarks in it. For example, I >>> agree that adding tags would be nice, or the need to have a way to get >>> items count. >> I working to integrate these edits by myself and propose to accept the >> new version since it seems that nobody if not me. > > I'd like to work on this too, any public wiki or similar way to work ? I > don't > know how things are done usually. > There are GIT repo for XEPs and other stuff: git://gitorious.org/xmpp/xmpp.git but I don't know this process in detail too. > > I have talked to the guys of buddycloud on the MUC room, they plan to propose > they XEP for standardisation, but want to prove by code that it works before > that. I adviced them to publish the comment/experiment here. > That will be interesting. -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
