Re: [Standards] Message Mine'ing
Thanks for the explanation. Grokkage in progress. Questions shall follow. > On Tue Dec 2 19:10:12 2008, Peter Saint-Andre wrote: >> Dave Cridland wrote: >> >> > I'm wondering if we can split the issue, here, and instead have >> two >> > mini-protocols: >> > >> > 1) The "Hey, I have pending messages here!" one. (ie, a >> bare_jid-wide >> > version of the flashing taskbar item thingy.) >> > >> > I'm wondering if intra-jid presence can be made to do the first - >> so the >> > clients would send a directed presence to their own bare jid which >> > contained "private" status, including any pending messages. >> > >> > Assuming the intra-jid presence trick can be used, then servers >> need to >> > do nothing. Otherwise, I'm tempted to suggest that we simply >> standardize >> > that hack, and then we've a general method for doing similar >> things. >> >> Presence, message, what difference does it make? I see no special >> reason >> to use presence instead of message here, in fact it doesn't have >> anything to do with presence so I'd prefer message. >> >> > Well, I picked presence for two reasons. Firstly, it does have to do > with the client status, which is arguably presence rather than a > message. Secondly, it has the routing properties we want without > having to change the server at all, which is, to say the least, > rather convenient. > > >> Then the question is: does your proposal (which I don't grok, >> perhaps >> you could post more details) cut out the server in a way that the >> MINE >> stuff doesn't? Are you perhaps suggesting a generalized algorithm >> for >> construction of a UUID for each message, so that the claiming >> client can >> send a special message (or presence) to the other resources so that >> the >> others know it has claimed the message? >> >> > No, not at all. I'd assumed that only a single session would get the > message, rather than all of them. This means that instead of having a > message, and then having to "claim" it, the client would look for > other clients which had unseen messages and get them resent to it if > the user appeared to be looking for them. > > >> I think I'm missing something here. Yes it would be nice if we >> didn't >> need to change any servers to make this happen (just make it so that >> they send bare-JID message to all resources), > > No, that's the bit I'm proposing need not be changed. > >> but it's not clear to me >> how we can make that work. > > So... My desktop gets a message: > >to='[EMAIL PROTECTED]/desktop-client'> > You still there? > > > But, sadly, I'm not there - I've walked into the ktchen to boil the > kettle. Luckily, I do have my mobile device upon me. My desktop > client doesn't know I'm not there, it only knows I've not yet waved > my mouse upon the window, so it's doing the orange-flashy-thing in my > taskbar. (These things probably have good, proper, names.) > > But, as well as that, it also does this: > > > > > > > > > Now, my other clients all see this, and can Ding accordingly, flash > their taskbar bits, or whatever else it is that they do. (They might > do this only after a short period, of course, but then, my desktop > client might only send out intra-jid presence updates after a short > period, too). > > As it happens, I hear the ding whilst the kettle boils, and look at > my mobile device - sure enough, there's a notification with stpeter's > name in it. Since, yea, even unto the tea break, I wait upon every > word that he doth utter, I open up the message eagerly. > > And the mobile device *then* can ask my desktop client for the > message (via XEP-0146, or something that perhaps only gets messages > from a single jid), and show it to me. > > I reckon the user experience is spot on, there, covers all the > use-cases, and really, the only disadvantage I see is that I was > actually quite keen on a big button marked "Release Mines". > > OTOH, it does keep priority based routing, and allows it to remain a > feature instead of a plague - but one that users can gleefully > ignore. To be fair, though, it doesn't work well with servers that > broadcast messages to equal priorities - I'm not sure it hurts that > much, though. > > Dave. > -- > Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED] > - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ > - http://dave.cridland.net/ > Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade >
Re: [Standards] Deprecate XEP-0013 (Flexible Offline Message Retrieval)?
Kevin Smith wrote: >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matthias >> Wimmer >> Well I do have an implementation of it ;) > > On Thu, Nov 27, 2008 at 2:17 PM, Rv, Srivatsa <[EMAIL PROTECTED]> wrote: >> Yes, Even we have it! > > Then I guess we need a replacement if we get rid of it :) Well, nothing brings out the implementors like the idea of deprecating a protocol. Maybe we need to do that more often. ;-) I'm fine with keeping it for a while (or indefinitely), but I had been under the impression that the protocol was not widely implemented or deployed. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] Message Mine'ing
On Tue Dec 2 19:10:12 2008, Peter Saint-Andre wrote: Dave Cridland wrote: > I'm wondering if we can split the issue, here, and instead have two > mini-protocols: > > 1) The "Hey, I have pending messages here!" one. (ie, a bare_jid-wide > version of the flashing taskbar item thingy.) > > I'm wondering if intra-jid presence can be made to do the first - so the > clients would send a directed presence to their own bare jid which > contained "private" status, including any pending messages. > > Assuming the intra-jid presence trick can be used, then servers need to > do nothing. Otherwise, I'm tempted to suggest that we simply standardize > that hack, and then we've a general method for doing similar things. Presence, message, what difference does it make? I see no special reason to use presence instead of message here, in fact it doesn't have anything to do with presence so I'd prefer message. Well, I picked presence for two reasons. Firstly, it does have to do with the client status, which is arguably presence rather than a message. Secondly, it has the routing properties we want without having to change the server at all, which is, to say the least, rather convenient. Then the question is: does your proposal (which I don't grok, perhaps you could post more details) cut out the server in a way that the MINE stuff doesn't? Are you perhaps suggesting a generalized algorithm for construction of a UUID for each message, so that the claiming client can send a special message (or presence) to the other resources so that the others know it has claimed the message? No, not at all. I'd assumed that only a single session would get the message, rather than all of them. This means that instead of having a message, and then having to "claim" it, the client would look for other clients which had unseen messages and get them resent to it if the user appeared to be looking for them. I think I'm missing something here. Yes it would be nice if we didn't need to change any servers to make this happen (just make it so that they send bare-JID message to all resources), No, that's the bit I'm proposing need not be changed. but it's not clear to me how we can make that work. So... My desktop gets a message: to='[EMAIL PROTECTED]/desktop-client'> You still there? But, sadly, I'm not there - I've walked into the ktchen to boil the kettle. Luckily, I do have my mobile device upon me. My desktop client doesn't know I'm not there, it only knows I've not yet waved my mouse upon the window, so it's doing the orange-flashy-thing in my taskbar. (These things probably have good, proper, names.) But, as well as that, it also does this: Now, my other clients all see this, and can Ding accordingly, flash their taskbar bits, or whatever else it is that they do. (They might do this only after a short period, of course, but then, my desktop client might only send out intra-jid presence updates after a short period, too). As it happens, I hear the ding whilst the kettle boils, and look at my mobile device - sure enough, there's a notification with stpeter's name in it. Since, yea, even unto the tea break, I wait upon every word that he doth utter, I open up the message eagerly. And the mobile device *then* can ask my desktop client for the message (via XEP-0146, or something that perhaps only gets messages from a single jid), and show it to me. I reckon the user experience is spot on, there, covers all the use-cases, and really, the only disadvantage I see is that I was actually quite keen on a big button marked "Release Mines". OTOH, it does keep priority based routing, and allows it to remain a feature instead of a plague - but one that users can gleefully ignore. To be fair, though, it doesn't work well with servers that broadcast messages to equal priorities - I'm not sure it hurts that much, though. Dave. -- Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED] - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] Message Mine'ing
On Dec 2, 2008, at 14:50, Kevin Smith wrote: Mineing solves most things fine, apart from the one issue of when something should be un-mined. I had thought that what was being suggested was that when a user leaves one machine to go to another, he should hit a button on the machine labeled "release Mines", which could either change presence, or send or any number of other notifications. Roughly equivalent to this is that when the user reaches the new machine, he can do some Remote Controlled "release Mines" on the other client. If this was the case (and I'm assuming it's not, and hoping someone will explain to me where I went wrong), then the user could just as easily hit the "lower my priority" button (either locally or remotely) as the "release Mines" button, which would in turn leave the new client with a higher priority and therefore get stuff routed to it without a Mine. Ok, this is the "I leave chat windows open forever" scenario. I was concentrating on the (arguably more common) "I leave chat windows open for a little while" scenario[1]. Hopefully, the following words aren't too long (-: For "your" scenario, I don't know if there's a way to avoid the user doing something to change state (locally or remotely), or clients being aggressive on their recipient address resets (e.g. fairly short timeouts, which I don't think are as wrong and/or evil as others). For "my" scenario, mine-ing gets closer to the ideal than presence/ priority changes. This is even more true when client's use the > chat state (which I'm seeing more and more frequently). I hope this helps, at least explain my enthusiasm (-: -- Matthew A. Miller [EMAIL PROTECTED] [1] I argue it is more common because that's the behavior I see with most of my colleagues, customers, family, and friends. If I didn't work for an organization that lives and breathes this, I wouldn't try to argue the point too vigorously (-: smime.p7s Description: S/MIME cryptographic signature
Re: [Standards] Message Mine'ing
Jonathan Schleifer wrote: > Am 02.12.2008 um 22:24 schrieb Peter Saint-Andre: > >> I think that XEP-0085 is fine as a hint to unlock and send to >> the bare JID again. > > I think we should get that confusion and mess about session termination > vs. fixed first. Right, and that gets back to the definition of threads and chat sessions, which we've never settled. Oddly, people seem to adjust quite well to the messy reality of not having neat definitions... /psa
[Standards] Getting pending subscription requests
In http://xmpp.org/extensions/xep-0060.html#owner-subreq-pernode , a per-node request (of pending subscriptions) is to be made using Ad-hoc Commands. The Openfire implementation returns a child and looking at the Ad-hoc Commands spec, http://xmpp.org/extensions/xep-0050.html#execute-multiple , under example 15, it looks like this is indeed the correct behavior. In the Pubsub spec, however, the success result (example 169) is an empty (no child). Should the Pubsub spec be corrected or should the Ad-hoc Command spec make clear that an iq response can be completely empty? Also the wording in Pubsub seems a little unclear: "the owner then MAY request pending subscription approval requests". I think it would be more clear that there is to be an actual change of state, if the word "submit" is used in place of the first "request". Also the example's title is similarly confusing: "Owner requests all pending subscription requests for a node", since it seems to me that this section is talking about approving the subscriptions. And lastly, any responses on my previous emails? thanks, Brett
Re: [Standards] Message Mine'ing
On Tue, Dec 2, 2008 at 9:34 PM, Matthew A. Miller <[EMAIL PROTECTED]> wrote: >> It's not that I mind changing presence - what I wonder, though, is >> that if some user interaction is required, couldn't the user set their >> priority instead? I wonder how far that would get us. > Presence priority gets us mostly there if the user is proactive. Mine-ing > gets us more there if the user is reactive. > Human beings are already wired to be reactive, and mine-ing exploits that > (-: Right, that's what I don't see yet - could someone explain it to me in really short words, please? So everyone can understand my misunderstanding: Mineing solves most things fine, apart from the one issue of when something should be un-mined. I had thought that what was being suggested was that when a user leaves one machine to go to another, he should hit a button on the machine labeled "release Mines", which could either change presence, or send or any number of other notifications. Roughly equivalent to this is that when the user reaches the new machine, he can do some Remote Controlled "release Mines" on the other client. If this was the case (and I'm assuming it's not, and hoping someone will explain to me where I went wrong), then the user could just as easily hit the "lower my priority" button (either locally or remotely) as the "release Mines" button, which would in turn leave the new client with a higher priority and therefore get stuff routed to it without a Mine. Clearly some part of the puzzle has passed me by - I'm not trying to be belligerent, I'm just missing that piece. > Within the first 60 minutes of reading this spec, there were about half a > dozen ways I could see to implement this in the clients I work on regularly. > Some prototyping has shown that the protocol's got what I need (so far), > it's just a usability/implementation issue to resolve. Great then. /K
Re: [Standards] Message Mine'ing
Am 02.12.2008 um 22:24 schrieb Peter Saint-Andre: I think that XEP-0085 is fine as a hint to unlock and send to the bare JID again. I think we should get that confusion and mess about session termination vs. fixed first. -- Jonathan PGP.sig Description: This is a digitally signed message part
Re: [Standards] Message Mine'ing
On Dec 2, 2008, at 14:10, Kevin Smith wrote: Now I understand it a bit better, I think it probably does solve the problem it's setting out to solve, mostly (although it can't help in the case where someone leaves one machine to go to another, and the now idle client continues to receive a conversation unless we mandate that you must go Away (or similar) when leaving your machine, and if we did that we may as well stick with priorities.) Hopefully, adding the XEP-146 interaction section will make this more clear. If we think this important to do without changing presence, we can either reuse XEP-85 "gone", or add a new state of "moved" that is an unlock hint. It's not that I mind changing presence - what I wonder, though, is that if some user interaction is required, couldn't the user set their priority instead? I wonder how far that would get us. Presence priority gets us mostly there if the user is proactive. Mine- ing gets us more there if the user is reactive. Human beings are already wired to be reactive, and mine-ing exploits that (-: NOTE: I am not suggesting we do away with presence priority. I think there's still value there as a rough passive indicator to a user's attentiveness. What's not clear to me is how a client knows that it's the active client in order to Mine the message - should it be displayed to the user on all clients, and then withdrawn from view after it's been Mined elsewhere (Client UI question), with a client only mineing it when the user is known to have read it somehow? That was the intent. The "known to have read it somehow" bit has some suggestions in the implementation notes. I look at that as mostly a UI issue, not a protocol issue. As long as it is possible to sanely represent the protocol in the client, I'm happy - it would become a protocol issue if there was no reasonable way to present it to the user, I think. Within the first 60 minutes of reading this spec, there were about half a dozen ways I could see to implement this in the clients I work on regularly. Some prototyping has shown that the protocol's got what I need (so far), it's just a usability/implementation issue to resolve. /K -- Matthew A. Miller [EMAIL PROTECTED] smime.p7s Description: S/MIME cryptographic signature
Re: [Standards] Message Mine'ing
Jonathan Schleifer wrote: > Am 02.12.2008 um 21:55 schrieb Joe Hildebrand: > >> Hopefully, adding the XEP-146 interaction section will make this more >> clear. If we think this important to do without changing presence, we >> can either reuse XEP-85 "gone", or add a new state of "moved" that is >> an unlock hint. > > Maybe we want threads in the core so we can have threads and move them? We have threads in RFC 3921 but no one really / fully implements them. I think that XEP-0085 is fine as a hint to unlock and send to the bare JID again. /psa
Re: [Standards] Message Mine'ing
Jonathan Schleifer wrote: Am 02.12.2008 um 22:02 schrieb Jack Erwin: Blocking inbound messages with privacy lists can give you this behavior. Not a good idea, as they would be silently dropped and no error returned. Fair enough. This is not an issue with the current spec, though: The receiving server MUST send a copy of the ownership request to each of that user's non-negative priority resources. It is only an issue if we replace priority altogether. If we were to do that, then I am sure that we could come up with a mechanism that is better than negative priority for this. Regards, Jack
Re: [Standards] Message Mine'ing
On Tue, Dec 2, 2008 at 8:55 PM, Joe Hildebrand <[EMAIL PROTECTED]> wrote: >> That's ok - when it's not the only online resource, mcabber will know >> (through mine-ing) that it's not being talked to, so there's no reason >> for it to be logging the messages. > I would suggest that it could remove them from the log when another client > Mine's them, if that's the behavior you're after. That's what I said ;) >> Now I understand it a bit better, I think it probably does solve the >> problem it's setting out to solve, mostly (although it can't help in >> the case where someone leaves one machine to go to another, and the >> now idle client continues to receive a conversation unless we mandate >> that you must go Away (or similar) when leaving your machine, and if >> we did that we may as well stick with priorities.) > Hopefully, adding the XEP-146 interaction section will make this more clear. > If we think this important to do without changing presence, we can either > reuse XEP-85 "gone", or add a new state of "moved" that is an unlock hint. It's not that I mind changing presence - what I wonder, though, is that if some user interaction is required, couldn't the user set their priority instead? I wonder how far that would get us. >> What's not clear to me is how a client knows that it's the active >> client in order to Mine the message - should it be displayed to the >> user on all clients, and then withdrawn from view after it's been >> Mined elsewhere (Client UI question), with a client only mineing it >> when the user is known to have read it somehow? > > That was the intent. The "known to have read it somehow" bit has some > suggestions in the implementation notes. I look at that as mostly a UI > issue, not a protocol issue. As long as it is possible to sanely represent the protocol in the client, I'm happy - it would become a protocol issue if there was no reasonable way to present it to the user, I think. /K
Re: [Standards] Message Mine'ing
Am 02.12.2008 um 22:02 schrieb Jack Erwin: Blocking inbound messages with privacy lists can give you this behavior. Not a good idea, as they would be silently dropped and no error returned. -- Jonathan PGP.sig Description: This is a digitally signed message part
Re: [Standards] Message Mine'ing
Am 02.12.2008 um 21:55 schrieb Joe Hildebrand: Hopefully, adding the XEP-146 interaction section will make this more clear. If we think this important to do without changing presence, we can either reuse XEP-85 "gone", or add a new state of "moved" that is an unlock hint. Maybe we want threads in the core so we can have threads and move them? -- Jonathan PGP.sig Description: This is a digitally signed message part
Re: [Standards] Unified Cloud Interface (UCI) for XMPP
Reuven Cohen wrote: > On Tue, Dec 2, 2008 at 3:56 PM, Peter Saint-Andre <[EMAIL PROTECTED]> wrote: >> Sounds interesting! Do you have a draft spec for us to read? > > We're currently working on the details over at > http://groups.google.com/group/cloudforum OK. I joined that list so I suppose I'll see the discussion. :) Peter
Re: [Standards] Message Mine'ing
Dirk Meyer wrote: First of all, we need some sort of negative priority for bots. IMHO it maes no sense to send a message to a device that can not answer. Blocking inbound messages with privacy lists can give you this behavior. My laptop receives the message and tries to notify me. After a user defined timeout the laptop sends the "Hey, I have pending messages here!" message to my mobile phone and the phones makes noise. When I look at the phone, the phones says "Give me the pending message" to my laptop. As long as the client is getting modified the mobile phone client could wait to notify you when the message has not been "mine'd" within some configurable timeout. This way, the clients would not have to be synced up feature-wise. Regards, Jack
Re: [Standards] Unified Cloud Interface (UCI) for XMPP
On Tue, Dec 2, 2008 at 3:56 PM, Peter Saint-Andre <[EMAIL PROTECTED]> wrote: > Sounds interesting! Do you have a draft spec for us to read? > We're currently working on the details over at http://groups.google.com/group/cloudforum reuven
Re: [Standards] Unified Cloud Interface (UCI) for XMPP
Sounds interesting! Do you have a draft spec for us to read? Reuven Cohen wrote: > Hello Everyone, > > This is my first post to the XMPP standards list. > > A few months ago a number of us came together to create "The Cloud > Computing Interoperability Forum". The purpose of this group is to > discuss the creation of a common cloud computing interface. The group > is made up of a some of the largest cloud related vendors and startups > who all share the goal of cloud interoperability as well reducing > cross cloud complexity. (http://groups.google.com/group/cloudforum) > > I'd like to take a moment to explain my cloud interoperability ideas. > After various conversations, our concept is starting to take shape and > is based on what I'm called the "unified cloud interface" (aka cloud > broker). The cloud broker will serve as a common interface for the > interaction with remote platforms, systems, networks, data, identity, > applications and services. A common set of cloud definitions will > enable vendors to exchange management information between remote cloud > providers. > > The unified cloud interface (UCI) or cloud broker will be composed of > a specification and a schema. The schema provides the actual model > descriptions, while the specification defines the details for > integration with other management models. UCI will be implemented as > an extension to the Extensible Messaging and Presence Protocol (XMPP) > specifically as a XMPP Extension Protocol or XEP. > > The unified cloud model will address both Platform as a service > offerings such as Google App Engine, Azure and Force.com as well as > infrastructure cloud platforms such as Amazon EC2. Ultimately this > model will enable a decentralized yet extensible hybrid cloud > computing environment with a focus on secure global asynchronous > communication. > > Once we are in general agreement on the draft proposal, it will be > submitted for approval by the Internet Engineering Task Force (IETF) > for inclusion as a XMPP Extension and presented at the IEEE > International Workshop on Cloud Computing (Cloud 2009) being held in > May 18-21, 2009, in Shanghai, China. > > My draft is based on a combination of working being done in > conjunction to XMPP, CIM, Xam and several other standardization > efforts. > > Comments welcome. >
Re: [Standards] Message Mine'ing
On Dec 2, 2008, at 12:40 PM, Kevin Smith wrote: On Tue, Dec 2, 2008 at 7:25 PM, Jonathan Schleifer <[EMAIL PROTECTED]> wrote: I wouldn't want that, I really wouldn't want that. I have an mcabber That's ok - when it's not the only online resource, mcabber will know (through mine-ing) that it's not being talked to, so there's no reason for it to be logging the messages. I would suggest that it could remove them from the log when another client Mine's them, if that's the behavior you're after. Now I understand it a bit better, I think it probably does solve the problem it's setting out to solve, mostly (although it can't help in the case where someone leaves one machine to go to another, and the now idle client continues to receive a conversation unless we mandate that you must go Away (or similar) when leaving your machine, and if we did that we may as well stick with priorities.) Hopefully, adding the XEP-146 interaction section will make this more clear. If we think this important to do without changing presence, we can either reuse XEP-85 "gone", or add a new state of "moved" that is an unlock hint. What's not clear to me is how a client knows that it's the active client in order to Mine the message - should it be displayed to the user on all clients, and then withdrawn from view after it's been Mined elsewhere (Client UI question), with a client only mineing it when the user is known to have read it somehow? That was the intent. The "known to have read it somehow" bit has some suggestions in the implementation notes. I look at that as mostly a UI issue, not a protocol issue. -- Joe Hildebrand
Re: [Standards] Message Mine'ing
Am 02.12.2008 um 20:37 schrieb Matthew A. Miller: I assert that message mine-ing would actually solve your problem better than presence priorities. How? IMO, that works perfectly. I don't have to do anything manually. The message usually just goes where I am, thanks to automatically adjusting priority and auto away after 5 minutes. :) -- Jonathan PGP.sig Description: This is a digitally signed message part
Re: [Standards] Message Mine'ing
Peter Saint-Andre wrote: >> ejabberd already does this if there is more than one resource with the >> highest prio. If you have for example two resources with prio 50 and one >> with prio 30, both with prio 50 will receive messages to the bare JID. > > Most servers do that. What I'm suggesting is more of the Google Talk > behavior -- a message sent to the bare JID gets sent to *all* resources > regardless of priority. That is, priority is ignored and maybe even > deprecated. First of all, we need some sort of negative priority for bots. IMHO it maes no sense to send a message to a device that can not answer. That said, I have a scenario were you may want priorities: I have my mobile phone is my pocket and when I get a message, it makes a small noise. When working at my laptop, I do not want the phone to react on new messages at all. The phone has prio 30 and my laptop 50. If I go away and auto away kicks in, the laptop will be 20 and the phone gets the messages. On the other hand, if a message arives at my laptop and I just left the room (auto away has not kicked in yet), I want to know about that message. I like the idea from Dave: The "Hey, I have pending messages here!" one. (ie, a bare_jid-wide version of the flashing taskbar item thingy.) My laptop receives the message and tries to notify me. After a user defined timeout the laptop sends the "Hey, I have pending messages here!" message to my mobile phone and the phones makes noise. When I look at the phone, the phones says "Give me the pending message" to my laptop. Does this scenario make sense? Dirk -- Pascal: A programming language named after a man who would turn over in his grave if he knew about it. -- Datamation, January 15, 1984
Re: [Standards] Message Mine'ing
On Tue, Dec 2, 2008 at 7:25 PM, Jonathan Schleifer <[EMAIL PROTECTED]> wrote: > I wouldn't want that, I really wouldn't want that. I have an mcabber That's ok - when it's not the only online resource, mcabber will know (through mine-ing) that it's not being talked to, so there's no reason for it to be logging the messages. Now I understand it a bit better, I think it probably does solve the problem it's setting out to solve, mostly (although it can't help in the case where someone leaves one machine to go to another, and the now idle client continues to receive a conversation unless we mandate that you must go Away (or similar) when leaving your machine, and if we did that we may as well stick with priorities.) What's not clear to me is how a client knows that it's the active client in order to Mine the message - should it be displayed to the user on all clients, and then withdrawn from view after it's been Mined elsewhere (Client UI question), with a client only mineing it when the user is known to have read it somehow? /K
Re: [Standards] Message Mine'ing
On Dec 2, 2008, at 12:25, Jonathan Schleifer wrote: I wouldn't want that, I really wouldn't want that. I have an mcabber connected all the time on my router with priority 0. It's rarely used and never used when any other client is connected. When connecting from any of my other machines, the piority is 50 (if I'm using both and none gets idle). So I get new messages to every machine. That's ok. But I wouldn't want to also get it to my router, as there's no need for that and would make merging logs a PITA once we have server-side, encrypted chat logs (I plan to merge the logs of all my clients into server-side logs then, so this will be a real PITA then). I assert that message mine-ing would actually solve your problem better than presence priorities. -- Jonathan -- Matthew A. Miller [EMAIL PROTECTED] smime.p7s Description: S/MIME cryptographic signature
Re: [Standards] Message Mine'ing
> I wouldn't want that, I really wouldn't want that Presence-based routing has always been a usability nightmare, and Googles' implementation improves upon that quite a bit. However, it's not perfect, hence the message mine-ing, which would probably solve your (very advanced) use case. cheers, Remko
Re: [Standards] Message Mine'ing
Am 02.12.2008 um 20:14 schrieb Peter Saint-Andre: Most servers do that. What I'm suggesting is more of the Google Talk behavior -- a message sent to the bare JID gets sent to *all* resources regardless of priority. That is, priority is ignored and maybe even deprecated. I wouldn't want that, I really wouldn't want that. I have an mcabber connected all the time on my router with priority 0. It's rarely used and never used when any other client is connected. When connecting from any of my other machines, the piority is 50 (if I'm using both and none gets idle). So I get new messages to every machine. That's ok. But I wouldn't want to also get it to my router, as there's no need for that and would make merging logs a PITA once we have server- side, encrypted chat logs (I plan to merge the logs of all my clients into server-side logs then, so this will be a real PITA then). -- Jonathan PGP.sig Description: This is a digitally signed message part
Re: [Standards] Message Mine'ing
Jonathan Schleifer wrote: > Am 02.12.2008 um 20:10 schrieb Peter Saint-Andre: > >> (just make it so that they send bare-JID message to all resources) > > > ejabberd already does this if there is more than one resource with the > highest prio. If you have for example two resources with prio 50 and one > with prio 30, both with prio 50 will receive messages to the bare JID. Most servers do that. What I'm suggesting is more of the Google Talk behavior -- a message sent to the bare JID gets sent to *all* resources regardless of priority. That is, priority is ignored and maybe even deprecated. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] Message Mine'ing
Am 02.12.2008 um 20:10 schrieb Peter Saint-Andre: (just make it so that they send bare-JID message to all resources) ejabberd already does this if there is more than one resource with the highest prio. If you have for example two resources with prio 50 and one with prio 30, both with prio 50 will receive messages to the bare JID. -- Jonathan PGP.sig Description: This is a digitally signed message part
Re: [Standards] Message Mine'ing
Matthew A. Miller wrote: > I think that message mine-ing is a very elegant and simple solution to > determining user intent. Priority provides a course view of the user's > attentiveness and gets us mostly there, but requires users to be > proactive (e.g. diligently changing their presence). In fact, perhaps presence priorities would just disappear if we had something like this. Which I think might be a Good Thing. /psa
Re: [Standards] Message Mine'ing
Dave Cridland wrote: > I'm wondering if we can split the issue, here, and instead have two > mini-protocols: > > 1) The "Hey, I have pending messages here!" one. (ie, a bare_jid-wide > version of the flashing taskbar item thingy.) > > I'm wondering if intra-jid presence can be made to do the first - so the > clients would send a directed presence to their own bare jid which > contained "private" status, including any pending messages. > > Assuming the intra-jid presence trick can be used, then servers need to > do nothing. Otherwise, I'm tempted to suggest that we simply standardize > that hack, and then we've a general method for doing similar things. Presence, message, what difference does it make? I see no special reason to use presence instead of message here, in fact it doesn't have anything to do with presence so I'd prefer message. Then the question is: does your proposal (which I don't grok, perhaps you could post more details) cut out the server in a way that the MINE stuff doesn't? Are you perhaps suggesting a generalized algorithm for construction of a UUID for each message, so that the claiming client can send a special message (or presence) to the other resources so that the others know it has claimed the message? I think I'm missing something here. Yes it would be nice if we didn't need to change any servers to make this happen (just make it so that they send bare-JID message to all resources), but it's not clear to me how we can make that work. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] FW: XEP - 0060 - Multiple Subscriptions
Rv, Srivatsa wrote: > Hi, > > Mailing my query again as previous post of mine didn't draw any > response. A response to this query would be of great help to me. > > This is related to the multiple subscriptions to a single node as > mentioned under XEP 0060. > > My client has subscribed to a node twice and hence has two > subscription IDs. When there is a publication on that node, 1) Will > my client receive two messages or just one? One for each SubID. > 2) If it receives two > messages, is it possible to map the message to the corresponding > subscription id? Yes: http://xmpp.org/extensions/xep-0060.html#publisher-publish-success-subid /psa
[Standards] FW: XEP - 0060 - Multiple Subscriptions
Hi, Mailing my query again as previous post of mine didn't draw any response. A response to this query would be of great help to me. This is related to the multiple subscriptions to a single node as mentioned under XEP 0060. My client has subscribed to a node twice and hence has two subscription IDs. When there is a publication on that node, 1) Will my client receive two messages or just one? 2) If it receives two messages, is it possible to map the message to the corresponding subscription id? Thanks and Regards, Srivatsa The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.
