Re: [Standards] Planned Updates to XEP-0301 (Real Time Text) -- 1s vs 250ms interval
Mark Rejhon skrev 2011-08-19 00:02: Also, I point out that your paragraph "section 10.2 is sufficient" appears to contradict the next paragraph, "I do not think that is needed..." because section 10.2 implies that it is needed. I did not realize that you described a case with increasing latency. My comment was for a long but steady latency. Now to my second question: Do you want to change anything in the specification as a conclusion of this discussion? I suggest to not change anything, since we have what we need in section 10.2. /Gunnar
Re: [Standards] Planned Updates to XEP-0301 (Real Time Text) -- 1s vs 250ms interval
The GPRS networks where I have seen high latencies typically suffer from "buffer bloat". As a result, instead of dropping packets in the event of congestion, they just fill up the (overly large) buffers, demonstrating larger and larger queuing delays until finally the buffers are full, and (often multiple) losses ensue. TCP then backs off, and both rate (and delay) begin to build again. On Thu, Aug 18, 2011 at 6:02 PM, Mark Rejhon wrote: > > In most cases, you are right. However, it's also important to > determine what the latency spike is being caused by. GPRS is more > usually closer to 500ms-1000ms latency. Whenever there's a latency > spike, it's sometimes due to congestion, and if it is due to a > bandwidth starvation scenario, then lengthening the interval is the > best way to ensure the survival of XEP-0301 (where the alternative is > potentially a spontaneous disconnection or several seconds of lagging > oth of buffered-up 1000ms packets). Other times, latency spike are NOT > caused by bandwidth starvation issues or overload issues, but you do > not always know that. In situations of connections normally averaging > 1000ms or less, spiking to 3000ms, it is usually the safest and lesser > evil (less screen-to-screen latency) to lengthen the transmission > interval, in order to reduce screen-to-screen lag by reducing the > number of bytes that "piles up" in massive congestion. > > Also, I point out that your paragraph "section 10.2 is sufficient" > appears to contradict the next paragraph, "I do not think that is > needed..." because section 10.2 implies that it is needed. > > Sincerely, > Mark Rejhon >
Re: [Standards] Planned Updates to XEP-0301 (Real Time Text) -- 1s vs 250ms interval
> In situations of connections normally averaging > 1000ms or less, spiking to 3000ms, it is usually the safest and lesser > evil (less screen-to-screen latency) to lengthen the transmission > interval, in order to reduce screen-to-screen lag by reducing the > number of bytes that "piles up" in massive congestion. Also, latency spikes are often temporary (seconds to minutes). Which means the algorithm would quickly return it to 1 second. Remember GRPS is a shared resource and is not constant data rate because of bandwidth-availability fluctuations and reception fluctuations. For example: One second you might be allowed to transmit 5,000 bytes (~500ms TCP/IP ack) another few second, you may be able to transmit only 200 bytes or 300 bytes (>2000ms TCP/IP ack), next second, you're stalled for a couple seconds of no data throughput, next couple second, you manage to push out another ~2,000 bytes (~750ms TCP/IP ack) etc. GPRS is very bursty/fluctuating like that, especially when reception is low. In these specific cases, temporarily longer transmission intervals for XEP-0301 result in less screen-to-screen lag, because less bytes are congested because of the use of fewer packets. Also if many users are using the airwaves at once, it all slows down (like somebody multitasking telnet/ssh and FTP over a dial-up connection: the telnet/ssh connection becomes high-lag). Again, these are minority of cases, and this really chiefly appliable to mission-critical application use where you must also support good operation on narrowband systems. The simple case is to stay fixed at 1000ms interval, without regards to monitoring latency (i.e. section 10.2 of XEP-0301 spec is not required) Mark Rejhon
Re: [Standards] Planned Updates to XEP-0301 (Real Time Text) -- 1s vs 250ms interval
2011/8/18 Gunnar Hellström : > To me it seems that section 10.2 is sufficient, and your discussion is just > intended to clarify that, and give the mail list an example of one possible > algorithm. > > Though, if I understand the algorithm right ,GPRS with 3 second round-trip > would cause a transmission interval of 3 seconds or so. (?) I do not think > that it is needed to increase the transmission interval beyond one second > just because there is a long latency in the network. In most cases, you are right. However, it's also important to determine what the latency spike is being caused by. GPRS is more usually closer to 500ms-1000ms latency. Whenever there's a latency spike, it's sometimes due to congestion, and if it is due to a bandwidth starvation scenario, then lengthening the interval is the best way to ensure the survival of XEP-0301 (where the alternative is potentially a spontaneous disconnection or several seconds of lagging of buffered-up 1000ms packets). Other times, latency spike are NOT caused by bandwidth starvation issues or overload issues, but you do not always know that. In situations of connections normally averaging 1000ms or less, spiking to 3000ms, it is usually the safest and lesser evil (less screen-to-screen latency) to lengthen the transmission interval, in order to reduce screen-to-screen lag by reducing the number of bytes that "piles up" in massive congestion. Also, I point out that your paragraph "section 10.2 is sufficient" appears to contradict the next paragraph, "I do not think that is needed..." because section 10.2 implies that it is needed. Sincerely, Mark Rejhon
Re: [Standards] Planned Updates to XEP-0301 (Real Time Text) -- 1s vs 250ms interval
Mark Rejhon skrev 2011-08-18 16:29: One possible simpler congestion-recovery algorithm that complies with section 10.2 of XEP-0301 is simply using the average latency of the last several message delivery receipts (XEP-0184) to automatically set the interval, if it's longer than the default 1000ms. Mark, Do you propose that anything is modified in the specification because of your discussion? To me it seems that section 10.2 is sufficient, and your discussion is just intended to clarify that, and give the mail list an example of one possible algorithm. Though, if I understand the algorithm right ,GPRS with 3 second round-trip would cause a transmission interval of 3 seconds or so. (?) I do not think that it is needed to increase the transmission interval beyond one second just because there is a long latency in the network. Gunnar
Re: [Standards] Microblogging: XEP-0277 and beyond
On Thursday, August 18, 2011 05:10:58 AM Goffi wrote: > - the ability to get missed items between the last time a contact was > disconnected and the time it reconnect I have a protocol flow for reliable pubsub that I've not yet publicized, but essentially the idea is to include Result Set Management (XEP-0059) UID values in pubsub event notifications. The client can then notice if it missed an item and use iq-get to catch up. Maybe this could go in some "RSM with PubSub" XEP that sorely needs to be written. Justin
Re: [Standards] Microblogging: XEP-0277 and beyond
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: si...@buddycloud.com build your own open and federated social network - http://open.buddycloud.com
Re: [Standards] Proposed XMPP Extension: Extensible Status Conditions for Multi-User Chat
On Tue Aug 16 16:12:34 2011, Peter Saint-Andre wrote: On 8/16/11 3:35 AM, Dave Cridland wrote: > On Mon Aug 15 22:57:59 2011, Peter Saint-Andre wrote: >> > 2) We also need to consider that many clients only handle one status >> > code. >> >> Which one do they handle? >> >> > I mean they will only process one in a set. Sometimes they ignore all > but the first. Sometimes they ignore all but the last. Um, isn't that called a bug? Sure. But it certainly used to be sufficiently prevelant that you couldn't build a MUC implementation without taking it into account. 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] request for reviews: XEP-0045 v1.25rc5
Am 18.08.2011 15:43, schrieb Peter Saint-Andre: I've completed a round of revisions to XEP-0045 (Multi-User Chat) in an effort to incorporate developer feedback I've received since the last version 3 years ago. The XMPP Council would like to vote on these revisions before the end of September or possibly early October, so it would be great if folks could check the diff in the next few weeks: http://xmpp.org/extensions/diff/api/xep/0045/diff/1.24/vs/1.25rc5 A rendered version is here: http://xmpp.org/extensions/tmp/xep-0045-1.25.html Thanks for the update. I will try to read (again) as much as I can. At first I would strongly suggest to replace at least that 'oldhag' which is e.g. used for a new nick with something else. I've wondered some minutes when I first read that example in 7.6 until I have read further. For other people like me, who like stupid looking but easy to read docs, here is something I've done to my copy of XEP-0045 (.example and .test are reserved by RFC 2606): - sed \ -e 's/chat.shakespeare.lit/chat.example/g' \ -e 's/shakespeare.lit/home.test/g' \ -e 's/firstwitch/occupant1owner/g' \ -e 's/secondwitch/occupant2admin/g' \ -e 's/thirdwitch/occupant3none/g' \ -e 's/crone1/user1owner/g' \ -e 's/wiccarocks/user2admin/g' \ -e 's/hag66/user3none/g' \ -e 's/oldhag/newnick/g' \ -e 's/coven/room1/g' \ -i xep-0045.html - ;=) Regards, Alexander
[Standards] UPDATED: XEP-0296 (Best Practices for Resource Locking)
Version 0.2 of XEP-0296 (Best Practices for Resource Locking) has been released. Abstract: This document specifies best practices to be followed by Jabber/XMPP clients about when to lock into, and unlock away from, resources. Changelog: Expanded intro with a short problem description; moved chat states considerations to their own section; tightened requirement regarding a message from different resource from MAY to SHOULD; loosened requirement regarding a message with 'gone' from MUST to SHOULD; added missing but required sections (mam) Diff: http://xmpp.org/extensions/diff/api/xep/0296/diff/0.1/vs/0.2 URL: http://xmpp.org/extensions/xep-0296.html
[Standards] NEW: XEP-0304 (Whitespace Keepalive Negotiation)
Version 0.1 of XEP-0304 (Whitespace Keepalive Negotiation) has been released. Abstract: This specification defines a method for negotiating how to send keepalives in XMPP. Changelog: Initial published version. (psa) Diff: N/A URL: http://xmpp.org/extensions/xep-0304.html
Re: [Standards] Microblogging: XEP-0277 and beyond
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.
Re: [Standards] Simplicity/Complexity of XEP-0301 -- opinions?
> can be detected and trigger retransmission (see section 4.6.4 of > XEP-0301) in an advanced implementation of XEP-0301. That said, to prevent scaring programmers: I should stress that minimal implementation of XEP-0301 (following ONLY the 'REQUIRED'), is actually really simple. In my experience, it added only 500 lines of code to an existing instant messaging program. Very easy XEP-0301 is basically supporting ONLY the Tier 1 elements, XML action elements: insert text, backspace, and forward delete. (Note: They can be used for en-bloc operations, including cut, copy and paste behavior). If nobody on XMPP objects, I'm going to mention that 300ms interval is recommended, when following minimal XEP-0301 implementation, to avoid uncomfortable bursty output. As a simplicity test of XEP-0301, somebody (one of us) should add XEP-0301 support to Pidgin or Miranda, or one of the other open source XMPP clients, seeing how quickly we might be able to add the baseline feature in the first pass of programming. (and more complete XEP-0301 in a second pass of programming) Cheers Mark Rejhon
Re: [Standards] Planned Updates to XEP-0301 (Real Time Text) -- 1s vs 250ms interval
> Mark Rejhon skrev 2011-08-18 05:33: >> >> XEP-0301 has section 10.2 >> that suggests you can dynamically lengthen the transmission interval >> in order to survive extreme conditions like those you described. (i.e. >> 2,000 or 3,000ms). Please note that this is no longer really >> "REAL-time text" (it's only near-real time). > > I agree with Mark's conclusion. Automatic disabling of the real-time > text feature and falling back to message mode will confuse users who are > used to not needing any special action for their text to be sent. Yes, Gunnar makes a good point -- automatic mode changes are undesirable. One might view automatic changes of interval as a small mode change, too. Generally, in order of preference, for user-experience, it is: (1) Real time text smoothed presentation (natural typing or time-smoothed, 1000ms interval or less) (2) Short-latency real time text bursty presentation (near-fluid 300ms bursts) (3) Longer-latency "near real time" text smoothed presentation (natural typing or time-smoothed) (4) Longer-latency "near real time" text bursted presentation (uncomfortable bursts) (5) Message-by-Message mode (if this must be done, display a very clear indicator) The only situation I can see where it's necessary to make a "major mode change" when we're bandwidth-starved on dial-up-league links. However, this situation is so rare, it's not normally necessary to complicate programming in order to do this. My sample open source code at www.realjabber.org doesn't do this. It's just that XEP-0301 allows this flexibility, for a mission-critical application. One possible simpler congestion-recovery algorithm that complies with section 10.2 of XEP-0301 is simply using the average latency of the last several message delivery receipts (XEP-0184) to automatically set the interval, if it's longer than the default 1000ms. This would "automatically" survive the vast majority of congestion scenarios, including overloaded XMPP networks, as well as GRPS at 3000ms. Or if message delivery receipts is too frequent (one would be sent back every second), then using XMPP ping at regular intervals (say, once every X seconds, or once every X RTT packets), and using that for latency calculations to set the RTT latency.That way, when congestion dissapears, the latency is under 1000ms, and XEP-0301 is "back to normal" (default transmission interval) And by following section 10.2, the software become automatically "nice" to the XMPP network because we slow down our message deliveries if the XMPP network gets overloaded (network latencies go up). And, also, if using XEP-0184 message delivery confirmations, lost RTT transmissions can be detected and trigger retransmission (see section 4.6.4 of XEP-0301) in an advanced implementation of XEP-0301. Mark Rejhon
[Standards] request for reviews: XEP-0045 v1.25rc5
I've completed a round of revisions to XEP-0045 (Multi-User Chat) in an effort to incorporate developer feedback I've received since the last version 3 years ago. The XMPP Council would like to vote on these revisions before the end of September or possibly early October, so it would be great if folks could check the diff in the next few weeks: http://xmpp.org/extensions/diff/api/xep/0045/diff/1.24/vs/1.25rc5 A rendered version is here: http://xmpp.org/extensions/tmp/xep-0045-1.25.html Thanks! Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] Microblogging: XEP-0277 and beyond
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
Re: [Standards] Microblogging: XEP-0277 and beyond
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. > > > - 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. > > - 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 ? > > - 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 > > - 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. > [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
Re: [Standards] Microblogging: XEP-0277 and beyond
On 08/18/2011 07:10 PM, Goffi wrote: > G'day everybody, > > as it is my first post on @standard, I just quickly present myself: I'm the > developper of "Salut à Toi", a multi-frontend XMPP client (you can have a > presentation here ==> > http://www.goffi.org/post/2011/06/05/Salut-%C3%A0-Toi%3A- > a-multi-frontends-XMPP-client ). My client use microblogging, and I have an > implementation of XEP-0277 on it (with a dirty custom hack to have several > roster-access nodes), which was made before the replies/comments update. > > 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. > > - 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. > > - push notification when a contact is connected Presence?? :)) > > - 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 > > > > 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. > > - 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. > > - 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 > > - 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? > > > > I have heard about the buddycloud draft on the subject: > https://buddycloud.org/wiki/XMPP_XEP , and I think there are good ideas > there, > like using Message Archive Management ( > http://doomsong.co.uk/extensions/render/message-archive-management.html ) for > the date-based retrieving. I think that this feature can be omitted for the first time since it can be solved more easily. > > > 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 think it's important to focus on microblogging, as it become more and more > common these days. I also think that roster-access need special attention, > specially in server side: it's important to have permission management easy > for the end-user. That's ok but I think that we should work on independent solution that keeps in mind our own way (decentralized, flexibility, restrictions absence). > > Cheers > Jérôme Poisson (aka Goffi) > > PS: I have also worked on features for my client that I'd like to > standardize, > like a generic card games management. > Great thing! -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
[Standards] Microblogging: XEP-0277 and beyond
G'day everybody, as it is my first post on @standard, I just quickly present myself: I'm the developper of "Salut à Toi", a multi-frontend XMPP client (you can have a presentation here ==> http://www.goffi.org/post/2011/06/05/Salut-%C3%A0-Toi%3A- a-multi-frontends-XMPP-client ). My client use microblogging, and I have an implementation of XEP-0277 on it (with a dirty custom hack to have several roster-access nodes), which was made before the replies/comments update. 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 - the possibility to pull all items of severals peoples (e.g. a roster group) at once - push notification when a contact is connected - the ability to get missed items between the last time a contact was disconnected and the time it reconnect 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). - 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. - 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 - 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" ». I have heard about the buddycloud draft on the subject: https://buddycloud.org/wiki/XMPP_XEP , and I think there are good ideas there, like using Message Archive Management ( http://doomsong.co.uk/extensions/render/message-archive-management.html ) for the date-based retrieving. 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 think it's important to focus on microblogging, as it become more and more common these days. I also think that roster-access need special attention, specially in server side: it's important to have permission management easy for the end-user. Cheers Jérôme Poisson (aka Goffi) PS: I have also worked on features for my client that I'd like to standardize, like a generic card games management.
Re: [Standards] LAST CALL: XEP-0260 (Jingle SOCKS5 Bytestreams Transport Method)
I would also point out Tobias' request for clarification about the DST.ADDR computation: http://mail.jabber.org/pipermail/jingle/2011-August/001705.html
