Logs for jdev

Show join/part/nick changes:

[00:08:46] * mlundblad left the chat.
[00:48:31] * luca tagliaferri joined the chat.
[02:03:59] * Florob left the chat.
[02:26:02] * luca tagliaferri left the chat.
[02:57:24] * johnny left the chat.
[03:18:55] * johnny joined the chat.
[03:26:08] * smoku left the chat.
[03:44:17] * jcea left the chat.
[04:07:37] * johnny left the chat.
[04:07:50] * johnny joined the chat.
[04:20:29] * johnny left the chat.
[04:20:35] * johnny joined the chat.
[04:32:44] * fiusajr joined the chat.
[04:33:33] <fiusajr> Hi guys
[04:34:20] <fiusajr> Jdev==java developers?
[04:34:48] <waqas> No, see the room topic
[04:35:13] <waqas> "Jabber/XMPP Development"
[04:36:12] <fiusajr> What kind of porra is this???
[04:40:05] * fiusajr left the chat.
[04:44:01] * fiusajr joined the chat.
[04:47:14] <fiusajr> Im reading about xmpp...its very interest!!!
[04:52:15] <fiusajr> How do i do to execute a xml connecting in jabberd???
[04:54:30] <fiusajr> Anyone can response me???
[04:55:45] * fiusajr left the chat.
[04:56:07] * fiusajr joined the chat.
[04:56:07] * fiusajr left the chat.
[04:56:57] * fiusajr joined the chat.
[04:57:13] * Yagiza joined the chat.
[04:57:13] * fiusajr left the chat.
[04:58:08] * fiusajr joined the chat.
[04:58:16] * fiusajr left the chat.
[05:11:38] * Ludovic joined the chat.
[05:19:23] * waqas left the chat.
[05:20:02] * lastsky joined the chat.
[05:21:00] * lastsky left the chat.
[05:45:08] * Ludovic left the chat.
[05:53:59] * Yagiza left the chat.
[06:27:40] * darkrain left the chat.
[06:29:29] * darkrain joined the chat.
[06:29:45] * darkrain left the chat.
[06:29:47] * darkrain joined the chat.
[06:50:23] * teo1 joined the chat.
[07:01:12] * niekie left the chat.
[07:58:23] * mlundblad joined the chat.
[08:05:10] * jonas joined the chat.
[08:28:02] * Tobias joined the chat.
[08:28:33] * MattJ left the chat.
[08:40:24] * alfeberlin left the chat.
[08:49:38] * teo1 left the chat.
[08:49:39] * teo1 joined the chat.
[09:12:50] * teo1 left the chat.
[09:12:51] * teo1 joined the chat.
[09:18:30] * luca tagliaferri joined the chat.
[09:24:56] * nabatt joined the chat.
[09:39:50] * Alex joined the chat.
[10:02:14] * deryni joined the chat.
[10:16:35] * smoku joined the chat.
[10:28:44] * Zash joined the chat.
[10:32:55] * jcea joined the chat.
[10:33:48] * Zash left the chat.
[10:49:14] * Tobias left the chat.
[11:17:20] * will.thompson joined the chat.
[11:27:33] * Tobias joined the chat.
[12:21:24] <Tobias> does XMPP use IDNA2003 or IDNA2008?
[13:09:16] * Tobias left the chat.
[13:09:17] * Tobias joined the chat.
[13:16:19] * Tobias left the chat.
[13:43:17] * Tobias joined the chat.
[14:00:31] * louiz’ joined the chat.
[14:15:36] * Xificurk left the chat.
[14:25:10] * deryni left the chat.
[14:31:36] * Alex left the chat.
[14:34:09] <darkrain> Tobias: IDNA2003 (for the moment(?))
[14:34:25] <darkrain> Found your ICU issue? :P
[14:41:35] <Tobias> darkrain: yeah, prep works, just finishing IDNA stuff
[14:41:47] <darkrain> What was the issue?
[14:41:54] <Tobias> darkrain: you don't want to know ;)
[14:41:59] <darkrain> Yes, I do.
[14:42:02] <darkrain> !xmpp-address
[14:42:09] <Tobias> then i don't want to tell :P
[14:42:11] <darkrain> Oh, right, HAL's not here
[14:42:21] <Tobias> used the wrong variable to detect whether an error happend or not
[14:42:41] <darkrain> .
[14:47:06] * Tobias left the chat.
[14:49:41] * zanchin joined the chat.
[14:59:11] * duck1123 left the chat.
[14:59:22] * duck1123 joined the chat.
[15:10:31] * deryni joined the chat.
[15:30:51] * waqas joined the chat.
[15:51:09] * darkrain_ joined the chat.
[16:04:41] * аrtist joined the chat.
[16:05:13] * teo1 left the chat.
[16:05:56] * аrtist left the chat.
[16:07:41] * niekie joined the chat.
[16:14:59] * luca tagliaferri left the chat.
[16:24:55] * Xificurk joined the chat.
[16:27:23] * Kev_ left the chat.
[16:28:13] * Kev_ joined the chat.
[16:31:37] * jonas left the chat.
[16:33:54] * nabatt left the chat.
[16:42:01] * stpeter joined the chat.
[16:59:08] * teo1 joined the chat.
[17:02:03] * will.thompson left the chat.
[17:02:09] * will.thompson joined the chat.
[17:02:43] * evilotto joined the chat.
[17:23:37] * luca tagliaferri joined the chat.
[17:29:47] * Yagiza joined the chat.
[17:30:03] <Yagiza> Hello every1!
[17:30:18] <duck1123> hello Yagiza
[17:30:22] <louiz’> hello
[17:30:25] <stpeter> wow, github.com is slow
[17:30:51] <louiz’> I don't find it slow, currently
[17:31:08] <Yagiza> I just wanted to discuss PEP-related XEPs: 80, 84, 107, 108 and 118
[17:31:23] <louiz’> well, start discussing ;)
[17:31:34] <Yagiza> What about publisher resource?
[17:32:09] <stpeter> Yagiza: you mean the resourcepart of the publisher's JID?
[17:32:25] <Yagiza> Yes. XEP-0084 says 'bout using XEP-0033
[17:32:39] <Yagiza> XEP-0080 says nothing
[17:33:20] <Yagiza> But at least USer Geolocation is useless without resource part
[17:33:50] <Yagiza> Different resources hardly have the same location
[17:34:50] <Kev_> It's not the location of the resources, mind, it's the location of the user, and they probably only have one of those.
[17:35:15] <stpeter> :)
[17:35:33] <stpeter> right, all of the "user" XEPs are about the human, not the device
[17:36:20] <Yagiza> But we cannot determine which one of the devices user uses right now.
[17:36:28] <stpeter> that's what presence is for
[17:36:50] <duck1123> It would still be cool if it was bound to the resource so that your location is the location of the resource with the highest priority
[17:37:18] <Kev_> duck1123: Your location is whatever the location you publish is - you can publish it from whichever resource is appropriate.
[17:37:37] * smoku left the chat.
[17:37:45] <Yagiza> Ok. Now we have 5 resources and all of the have presence of the same type with the same priority.
[17:38:21] <stpeter> I don't understand your use case
[17:38:33] <Yagiza> And we want to show them on the map. Which of them where do we have to display?
[17:38:39] <stpeter> if the human changes location, the human should update the XEP-0080 node
[17:38:55] <stpeter> (that might happen automatically via the client)
[17:39:29] <stpeter> you want to show that my desktop machine is at home, my phone is in my pocket, and my laptop is in my office at work?
[17:40:03] <louiz’> yes, I think
[17:40:33] <duck1123> and then you would be wherever the device you're using is
[17:40:35] <louiz’> And that you're phiscally at the same place than your resource with the hioghest priority
[17:40:49] * smoku joined the chat.
[17:41:20] * tofu joined the chat.
[17:41:24] <stpeter> hmm
[17:41:55] <Kev_> We could define a disco extension :)
[17:42:05] <Yagiza> We cannot force user update his presence manually.
[17:42:23] <Yagiza> He can just forget to do it.
[17:43:06] <Yagiza> So, I wanted to suggest using resource part of the jid as an Item Id.
[17:43:18] <Yagiza> For those XEPs
[17:44:05] <Yagiza> The same is for tune: different devices can play different tunes the same time.
[17:44:24] <Yagiza> And they can have the same priority the same time.
[17:45:16] <Yagiza> It's a good idea to have a way to determine, which of the resources published the Personal Event.
[17:45:34] <Yagiza> What do you think?
[17:47:20] <stpeter> thinking :)
[17:47:32] <Kev_> Can we not already tell that?I thought we announced the publisher.
[17:47:36] <Kev_> Been a while since I've looked, though.
[17:48:18] <stpeter> in the latest version of the pubsub spec we added the 'publisher' attribute on event notifications
[17:48:29] <stpeter> but probably it's not widely supported yet
[17:48:48] <duck1123> IIRC, openfire doesn't support that
[17:49:21] * will.thompson left the chat.
[17:49:54] <Yagiza> Okay, i'll reread the specs right now.
[17:51:06] <stpeter> duck1123: probably not, because openfire is abandonware
[17:51:57] <duck1123> is it really? I've heard that complaint, but didn't know if that was true, or if people were just being critical
[17:55:12] <Yagiza> So, which servers do support that "publisher" attribute?
[17:56:09] <stpeter> it's abandonware, I think, unless someone proves otherwise!
[17:56:25] <stpeter> I contacted some of the developers a few weeks ago and I haven't heard anything from them
[17:56:37] <stpeter> I'll try to ask on the igniterealtime.org forum, too
[17:56:47] <stpeter> doing that now
[17:57:34] <Yagiza> Anyway, why using Item ID to store resource is not a good idea?
[18:00:17] <deryni> I believe openfire is officially "community-ware", or some such thing.
[18:00:33] <stpeter> Yagiza: you can experiment with that and report the results
[18:00:46] <stpeter> I think location is really a singleton: http://xmpp.org/extensions/xep-0060.html#impl-singleton
[18:02:27] <stpeter> it does seem that there are discussions at http://community.igniterealtime.org/community/developers/openfire_dev
[18:04:18] <Yagiza> I think that result is predictable: all my clients will behave correctly, but other clients will not be compatible to them, 'cause it is not mentioned in the XEP.
[18:05:09] <Yagiza> I'm talking about updating XEPs with recommendation to use Item Id for resource storing.
[18:06:05] <stpeter> that's what you want for your usecase, but that's not what I want for my usecase :)
[18:06:07] * SteveG joined the chat.
[18:06:17] <stpeter> I just want to publish my personal location, not my device location
[18:06:21] <Yagiza> In that case, all the client which needs to determine the resource, which published the item will use it. Others - will just ignore that information.
[18:06:24] <stpeter> and that's the intent for all these XEPs
[18:07:07] <waqas> stpeter: I haven't seen much IETF feedback/evaluation for 3921bis lately (as opposed to 3290bis and the address draft). Would that come later, or do people not have feedback?
[18:08:34] <duck1123> It seems like it would be best to store the resource-bound locations separately from the normal location and have the server update the singleton location based on presence.
[18:09:17] <Yagiza> stpeter: IC. But it seems a bad idea writing another XEPs for those who wish to use geolocation (and other PEP-related information) device-dependant.
[18:09:36] <Yagiza> I think it's better just to update existing XEPs...
[18:09:58] <stpeter> waqas: people don't have feedback -- we did have a security review, but the "Gen-ART" review yielded no feedback
[18:10:04] <Kev_> Well, except the point of PEP is that it's not device dependent.
[18:10:09] <Kev_> It's user only.
[18:10:22] <stpeter> waqas: however, IESG feedback is still on the way -- 3921bis hasn't been on an IESG agenda yet
[18:10:25] <Kev_> So it really is a new use case to have different e.g. geoloc for each device.
[18:10:37] <stpeter> Kev_: agreed
[18:12:12] <Yagiza> So, the primary idea is: the more XEP is beter
[18:12:22] <Kev_> The simpler a XEP is, the better.
[18:12:30] <stpeter> ok, context switch from i18n to security, gotta process some mods from my co-author on http://tools.ietf.org/html/draft-saintandre-tls-server-id-check-01 :)
[18:14:48] <waqas> I had some usecases for 'per-resource PEP'. The simplest approach seemed to be to let resources act as a PEP service (handling caps hash, etc), and reply with their stuff. Using something other than +notify has both upsides and downsides. An even simpler approach is to just put everything in <presence/> :)
[18:17:08] <duck1123> is there a XEP for archival of these types of values? So that you could query for the last sent location from a given resource.
[18:18:50] <waqas> There isn't. The most obvious would be a pubsub IQ item retrieval sent to the resource's full JID, but that of course requires implementation on the recipient's end.
[18:20:49] <darkrain_> Couldn't you do that with a more complete pubsub implementation on the bare JID?
[18:20:59] <duck1123> something like that would be useful for some of my usecases. (the last time Daniel was at /work, he was "aggrivated". The last time he was at /home, he was "happy"
[18:21:13] <waqas> darkrain_: Sure, or that.
[18:21:36] <darkrain_> :)
[18:22:08] <waqas> http://monitor.prosody.im/ for example has a bare JID per machine. It shouldn't need to.
[18:23:36] <darkrain_> .
[18:24:03] <MattJ> !slap waqas
[18:24:10] <waqas> !stab MattJ
[18:24:39] <darkrain_> MattJ: Is that 'memory free' or 'memory free or used for file cache'?
[18:25:11] <MattJ> darkrain, free
[18:26:25] <MattJ> waqas, I actually thing a bare JID per machine is perfect
[18:26:27] <MattJ> *think
[18:26:46] <MattJ> It allows access control - e.g. you can have more than one monitor account, each with access to different machines
[18:27:03] <Yagiza> Kev_, in my case the new XEP will be simpiest: XEP-XXXX: Just the same as XEP-0080, but Item Id attribute contains publisher's resource, to allow different devices publish different locations. Tha's all!
[18:27:25] <stpeter> Yagiza: that's a convention you're proposing for your use cases
[18:27:36] <darkrain_> It might be simplest; I'm not sure it's most elegant :/
[18:27:41] <stpeter> does that convention apply to anything except geolocation?
[18:27:53] <waqas> MattJ: For this use case perhaps, but for the general case of me wanting to monitor all my logged in devices, it isn't.
[18:28:09] <stpeter> e.g., user activity? user tune? etc.?
[18:28:12] <Yagiza> Yes. I just said about tune.
[18:28:35] <stpeter> Yagiza: sorry, I wasn't monitoring this room because I needed to finish another task
[18:28:55] <Yagiza> About Avatar... You said that yourself.
[18:29:15] <stpeter> but basically you want a way to publish device-specific information, not user-generic information
[18:29:39] <Yagiza> But you suggested using Extended Stanza Addressing, which looks ugly for me.
[18:29:59] <stpeter> one way to do that would be to overload the ItemID
[18:30:08] <stpeter> ESA is indeed ugly
[18:31:41] <Yagiza> But if this use case is not described in the XEP its implementation is not standard and there will be no compatibility with other software.
[18:31:56] <Yagiza> So I just wanted to mention this in the XEPs.
[18:35:13] <stpeter> it probably belongs in XEP-0163, because then it would apply to any payload spec that re-uses PEP
[18:36:13] * dendy joined the chat.
[18:36:46] <Yagiza> Yes
[18:37:54] <Yagiza> So, I think it's a good idea to discuss updating XEP-0163 with this recommenadation.
[18:39:31] <stpeter> hmm
[18:39:55] <stpeter> if you start publishing 5 different geolocations then you override the singleton nature of typical geoloc
[18:40:09] <stpeter> it's no longer user location, it's device location
[18:40:33] <stpeter> now, I grant that each payload format spec needs to say whether that payload should be a singleton or not
[18:40:40] <stpeter> and we need to update all those specs
[18:41:08] <stpeter> but if my client expects geoloc to be a singleton and it starts getting 5 different items, it might be confused
[18:41:24] <stpeter> and it wouldn't correlate those items with your presence resources
[18:41:41] <stpeter> so there are two different use cases here
[18:41:42] <duck1123> Yagiza: would my PEP archival idea work for your use case?
[18:41:49] <stpeter> user location vs. device location
[18:42:00] <stpeter> brb
[18:42:08] <waqas> Which means something like this should only happen if the contact supports it (via caps).
[18:42:22] <Yagiza> duck1123, never herd about it so far
[18:42:30] <Yagiza> heard
[18:42:41] <waqas> duck1123: What was your idea?
[18:43:36] <duck1123> basically the idea would be that whenever one of these properties is updated, it's stored somewhere with the resource that changed it. That way you could query for the last location from a given resource
[18:44:55] <waqas> That doesn't work as well for updates, unless the updates indicate which resource they are from.
[18:46:13] * Florob joined the chat.
[18:51:00] * Florob left the chat.
[18:51:13] * Florob joined the chat.
[19:05:09] * Yagiza left the chat.
[19:12:55] * Tobias joined the chat.
[19:19:03] * Neustradamus joined the chat.
[19:26:25] * jcea left the chat.
[19:31:11] * jcea joined the chat.
[19:56:35] * Tobias left the chat.
[20:03:08] * Tobias joined the chat.
[20:20:23] * Ludovic joined the chat.
[20:24:54] <Tobias> is memberbot down?
[20:25:07] * Xificurk left the chat.
[20:29:33] * Xificurk joined the chat.
[20:30:19] * lance joined the chat.
[20:34:30] <Tobias> ➡.ws = ➡.ws xn--hgi.wshg = xn--hgi.ws
[20:35:03] <Tobias> is it normal that ➡.ws via IDNAToASCII turns into xn--hgi.wshg? i expected xn--hgi.ws
[21:02:26] * lance left the chat.
[21:09:29] * nabatt joined the chat.
[21:18:23] * teo1 left the chat.
[21:18:24] * teo1 joined the chat.
[21:20:03] * smoku left the chat.
[21:20:19] * smoku joined the chat.
[21:21:21] * nabatt left the chat.
[21:33:07] <stpeter> Tobias: .wshg looks wrong to me
[21:33:40] <Tobias> stpeter: yup, it is...somehow ICU adds it if i call toUnicode before toASCII :/
[21:33:53] <stpeter> hmm
[21:33:58] <Tobias> well, ICU or my C/C++ code using ICU
[21:36:52] <waqas> That's weird Tobias. ToUnicode has no effect on a string that does not begin with the ACE prefix.
[21:37:17] <Tobias> not on the same string
[21:37:25] <Tobias> calling toUnicode on something at all
[21:37:41] <Tobias> makes toASCII add hg at the end
[21:37:50] <waqas> Show us the code :)
[21:38:35] <Tobias> waqas: http://pastebin.com/gtuPP851
[21:40:56] <waqas> Tobias: You are passing in the length of the ASCII string, not the unicode string. That's wrong, right?
[21:41:12] <Tobias> where?
[21:41:32] <waqas> That len variable being passed to uidna_IDNToUnicode is the length of the string you get from Lua, not the unicode string ustr.
[21:42:00] <Tobias> it's the same
[21:42:31] <waqas> Erm, the Lua string is in bytes, while the ustr is UChars :/
[21:43:00] <Tobias> ahh right
[21:43:02] <Tobias> argh
[21:43:03] <Tobias> thanks
[21:43:19] <Tobias> works now
[21:44:13] <waqas> And XMPP uses UIDNA_USE_STD3_RULES for prepping. It may make sense to pass it here.
[21:45:26] <Tobias> k
[22:09:51] * dendy left the chat.
[22:23:37] * Ludovic left the chat.
[22:32:50] * Tobias left the chat.
[23:01:26] * mlundblad left the chat.
[23:04:34] * Tobias joined the chat.
[23:21:46] * deryni left the chat.
[23:36:27] * stpeter left the chat.
[23:47:53] * Tobias left the chat.
[23:52:30] * MattJ left the chat.
[23:53:08] * Tobias joined the chat.
[23:53:20] * johnny left the chat.
[23:58:25] * luca tagliaferri left the chat.
[23:58:26] * luca tagliaferri joined the chat.
[00:02:09] * Tobias left the chat.
[00:04:24] * waqas left the chat.