Re: [Standards] UPDATED: XEP-0277 (Microblogging over XMPP)
On 5/23/12 1:28 AM, Sergey Dobrov wrote: > On 05/23/2012 03:24 AM, Peter Saint-Andre wrote: >> On 5/22/12 12:40 PM, Sergey Dobrov wrote: >> >> Well, the need to *change* it from the default to some reasonable value >> implies that the default value is unreasonable. That might depend on >> implementation and deployment (e.g., if someone runs an XMPP interface >> to an existing microblogging service, or a dedicated XMPP-based >> microblogging service, then the defaults might be perfectly reasonable). >> Thus I don't think the SHOULD is necessary here. It could say "verify >> that the max items setting is reasonable for microblogging purposes and >> change if necessary". > > Agree. > >> >> But I certainly might want to receive the last published item whenever I >> log in. This too seems like a setting that a dedicated microblogging >> service would tune in their configuration. >> > > Yes, it reasonable thing but do you think we should think about user > subscription preferences more deeply? Yes, but I doubt that we could say definitively that the configuration MUST or SHOULD be X for all users. >>> The meaning is just to provide easy way to obtain this very important >>> data by just retrieving some magic constant named item. >> >> We usually try to avoid magic values. :) >> > > It's a good position and perhaps it's good enough for pubsub nodes but > think about comments nodes: > > 1) extra node can lead to nodes names conflicts easier (again we need > some magic value to construct new node name) > 2) it's harder to clean up: to delete post from blog you will need three > retracts which can't be done atomic. Yes, I see your point. I don't see a good solution right now, but I will think about it some more. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] NEW: XEP-0313 (Message Archive Management)
On Fri, May 25, 2012 at 12:42 PM, Thijs Alkemade wrote: > > On 20 apr. 2012, at 10:32, Kevin Smith wrote: > >> On Thu, Apr 19, 2012 at 6:01 PM, Matthew Wild wrote: >>> One solution I came up with was for an entity that relays and archives >>> messages to stamp the message with: >> id="1234-5678"/> or >> id="8765-4321"/>. I'd be interested in feedback on this idea. >> >> Yes, we need (archiving, rather than stanza) ids stamped on the >> archived stanzas. >> >>> However even doesn't cover the case of the client knowing >>> the id of its *outgoing* messages. The server could echo them back >>> with ... but then things start to get a bit muddy. >>> The alternative is to not solve this, and clients should treat the MAM >>> archive as the canonical source of history - (therefore fetching >>> messages from the archive that have already been sent/received by it). >>> A waste of bandwidth if nothing else. >> >> You will only need to request (assuming you have carbons) on average >> less than a single message that's a duplicate, though - as IM is >> typically send a message/receive a message [yes, there are exceptions >> where this is potentially very untrue], and you will have the id of >> the message you received. >> > > > I've started implementing 0313 in libpurple/Adium, and I think > Matthew explained my concerns quite well. > > Your suggestion assumes that once a client receives an incoming > message from the server, everything the client sent before that > moment was received by the server successfully (it makes sense to > require Carbons to do MAM, but lets assume that Stream Management is > not enabled). Suppose the last session ended with these two > messages, on a high-latency connection which got interrupted: > > > If the client thinks message 12345 came before 9876, while the > server thinks it's the other way around, then requesting the archive > from abcde will duplicate message 12345. Yes. Always requesting based on the uid of the last message that you received will result in receiving from the server duplicates of any messages you have sent since then, and you'll have to not double-store them. 198 means that you know which of your sent stanzas have been processed by the server and does, I think, guarantee your history is complete and you're likely to end up, on average, with ~1 duplicated stanza to deal with on each login. The simple implementation is that you don't store in the cache anything that happened after the last message received from the server - and you know the ordering of your own stanzas vs the stanzas you received based on the ordering of the acks/messages you received from the server. /K
Re: [Standards] NEW: XEP-0313 (Message Archive Management)
On 20 apr. 2012, at 10:32, Kevin Smith wrote: > On Thu, Apr 19, 2012 at 6:01 PM, Matthew Wild wrote: >> One solution I came up with was for an entity that relays and archives >> messages to stamp the message with: > id="1234-5678"/> or > id="8765-4321"/>. I'd be interested in feedback on this idea. > > Yes, we need (archiving, rather than stanza) ids stamped on the > archived stanzas. > >> However even doesn't cover the case of the client knowing >> the id of its *outgoing* messages. The server could echo them back >> with ... but then things start to get a bit muddy. >> The alternative is to not solve this, and clients should treat the MAM >> archive as the canonical source of history - (therefore fetching >> messages from the archive that have already been sent/received by it). >> A waste of bandwidth if nothing else. > > You will only need to request (assuming you have carbons) on average > less than a single message that's a duplicate, though - as IM is > typically send a message/receive a message [yes, there are exceptions > where this is potentially very untrue], and you will have the id of > the message you received. > I've started implementing 0313 in libpurple/Adium, and I think Matthew explained my concerns quite well. Your suggestion assumes that once a client receives an incoming message from the server, everything the client sent before that moment was received by the server successfully (it makes sense to require Carbons to do MAM, but lets assume that Stream Management is not enabled). Suppose the last session ended with these two messages, on a high-latency connection which got interrupted: C: Hello S: Hey If the client thinks message 12345 came before 9876, while the server thinks it's the other way around, then requesting the archive from abcde will duplicate message 12345. On the other hand, if the client requests the archive starting from abcde and does not receive message 12345, it can not know for sure wether 12345 was even received by the server (the spec never mentions it, but in my opinion being able to mark a message as "we thought this message was sent, but the server never got it" is a necessary part of synchronizing your logs). Not a typical case, sure, but also not something that is very unlikely to ever occur, and I think it's important to keep the client's logs as consistent as possible. I don't really have a good solution to propose, though. Replying to every outgoing message with something that includes the UID it was logged with could work, but it might add quite a bit of overhead. Stream Management could help with the latter problem, but not the former. Regards, Thijs
