Home
jdev@conference.jabber.org
Tuesday, 14 April 2009< ^ >
stpeter has set the subject to: Jabber/XMPP Development | Logs: http://logs.jabber.org/jdev@conference.jabber.org/
Room Configuration

GMT-5
[00:29:35] teo leaves the room
[00:30:15] teo joins the room
[00:34:55] Kalyan joins the room
[00:43:08] mlundblad leaves the room
[00:45:40] johnny leaves the room
[01:03:48] nabatt joins the room
[01:14:05] johnny joins the room
[01:52:37] steve-e joins the room
[02:15:55] vArDo joins the room
[02:16:28] vArDo leaves the room: Be right back.
[02:18:44] vArDo joins the room
[02:25:32] Kev leaves the room: Logged out
[02:26:09] teo leaves the room: Replaced by new connection
[02:26:13] teo joins the room
[02:26:53] Kiwi joins the room
[02:31:45] MaxBecker joins the room
[02:38:40] waqas joins the room
[02:38:52] waqas leaves the room
[02:48:08] vArDo leaves the room: Disconnected
[02:49:23] mlundblad_laptop joins the room
[02:51:35] vArDo joins the room
[02:57:40] Kev joins the room
[02:57:58] sashok2k joins the room
[03:00:14] sashok2k leaves the room
[03:01:00] teo leaves the room
[03:01:17] teo joins the room
[03:05:36] remko joins the room
[03:10:16] Lega joins the room
[04:22:08] Christian joins the room
[04:34:14] remko leaves the room
[04:37:58] vArDo leaves the room
[04:44:47] wei joins the room
[04:49:20] mlundblad_laptop leaves the room: Replaced by new connection
[05:02:10] Grom leaves the room: Replaced by new connection
[05:02:14] Grom joins the room
[05:09:43] wei leaves the room
[05:14:18] mlundblad_laptop joins the room
[05:15:05] Kalyan leaves the room
[05:15:21] Kalyan joins the room
[05:15:33] qwp0 joins the room
[05:22:47] steve-e leaves the room: Replaced by new connection
[05:22:51] steve-e joins the room
[05:29:58] Lega leaves the room
[05:37:16] js joins the room
[05:44:02] js leaves the room
[05:50:03] pihhan joins the room
[05:59:07] MaxBecker leaves the room
[06:01:01] teo leaves the room
[06:01:17] teo joins the room
[06:14:10] js joins the room
[06:15:11] remko joins the room
[06:20:40] Yota_VGA joins the room
[06:31:00] waqas joins the room
[06:31:59] <waqas> Is xmpp.org having DNS issues again?
[06:32:01] steve-e leaves the room
[06:32:12] <waqas> Anyone know the IP?
[06:32:37] <remko> troncon@tux29> ping xmpp.org
PING xmpp.org (208.68.163.218) 56(84) bytes of data.
64 bytes from xmpp.org (208.68.163.218): icmp_seq=0 ttl=48 time=116 ms
[06:33:41] <waqas> Thanks remko
[06:34:52] <remko> np
[06:35:35] Kalyan leaves the room
[06:35:52] Kalyan joins the room
[06:37:19] vArDo joins the room
[06:38:56] Kalyan leaves the room
[06:41:16] AlekSi joins the room
[06:50:11] qwp0 leaves the room
[06:51:50] mlundblad_laptop leaves the room
[07:20:07] Lega joins the room
[07:32:32] Lega leaves the room: Replaced by new connection
[07:32:36] Lega joins the room
[07:33:22] waqas leaves the room
[07:49:06] pihhan leaves the room: Machine suspend
[08:01:53] pihhan joins the room
[08:02:09] <nabatt> Is in ejabberd some hook for disconnect session?
[08:20:04] MattJ joins the room
[08:23:28] <MattJ> nabatt, if you didn't find it already perhaps try the [ejabberd] chatroom or mailing list
[08:24:23] xepbot leaves the room: Disconnected: connection closed
[08:24:30] xepbot joins the room
[08:24:40] <MattJ> !ejabberd
[08:24:40] <xepbot> The ejabberd room is (on Jabber of course) at ejabberd@conference.jabber.ru
[08:24:44] <MattJ> Better :)
[08:39:45] waqas joins the room
[08:48:45] teo leaves the room
[08:55:32] Tobias joins the room
[08:59:36] <Tobias> howdy
[09:00:00] <waqas> Hi Tobias
[09:00:09] <Tobias> is there a pubsub setting so users automatically get unsubscribed if the get offline by disconnect or error or so?
[09:00:54] <waqas> PEP?
[09:01:53] <Tobias> it's for my monitoring project...all users are anonymous so if they go offline they don't need to be in the subscriber list
[09:02:16] <waqas> Use PEP then :)
[09:03:29] <Tobias> i don't have pep implemented...and on the other side this monitoring stuff is pretty unpersonal :D
[09:04:23] <Kev> If you have pubsub implemented, you have pep implemented ;)
[09:05:08] <MattJ> Far from it :)
[09:06:16] <Tobias> Kev: idavoll does pubsub
[09:06:19] <Tobias> but i guess no PEP
[09:07:33] <Kev> I don't know if idavoll does the newer bits of pubsub or not.
[09:07:39] <Kev> The PEPish bits.
[09:08:41] <Tobias> it's just if i publish stuff all 30 seconds and there are 500 people in the subscribed list the component will send them stuff which they won't receive and that results in load i don't need
[09:09:15] <Kev> Tobias: so use the presence subscription stuff then.
[09:10:05] AlekSi leaves the room
[09:10:36] waqas leaves the room: Replaced by new connection
[09:24:51] Grom leaves the room
[09:26:16] mog joins the room
[09:26:20] chriseb joins the room
[09:26:20] mog leaves the room: offline
[09:27:03] js leaves the room
[09:28:56] teo joins the room
[09:36:19] smoku joins the room
[09:44:16] jack leaves the room
[09:50:45] nabatt leaves the room
[09:51:30] Florob joins the room
[10:06:16] vArDo leaves the room
[10:08:49] Yota_VGA leaves the room
[10:10:37] wiretap leaves the room
[10:10:47] wiretap joins the room
[10:14:03] wiretap leaves the room
[10:14:11] wiretap joins the room
[10:20:10] smoku leaves the room
[10:25:20] stpeter joins the room
[10:26:10] wiretap leaves the room
[10:26:17] wiretap joins the room
[10:29:18] wiretap leaves the room
[10:29:26] wiretap joins the room
[10:30:22] pihhan leaves the room: Machine suspend
[10:30:46] wiretap leaves the room
[10:30:52] wiretap joins the room
[10:31:49] wiretap leaves the room
[10:31:56] wiretap joins the room
[10:40:45] jack joins the room
[10:44:12] ralphm joins the room
[10:44:47] <ralphm> stpeter: something occurred to me w.r.t to removal of disco publish
[10:45:11] wiretap leaves the room
[10:45:19] wiretap joins the room
[10:45:21] remko leaves the room: Logged out
[10:45:22] <ralphm> pubsub node configuration items can show up as meta data in disco info of such anode
[10:46:10] TuX joins the room
[10:46:11] <ralphm> so you could use node configuration to 'publish' more or less static data meant for discovery
[10:57:18] Kev leaves the room
[10:57:42] hawke joins the room
[11:03:34] <ermine> stpeter: hi, isn't it a typo in example 128 of xep 60 -- there is no <value/> element in the latest <field/> in that example?
[11:03:34] wiretap leaves the room
[11:03:40] wiretap joins the room
[11:05:09] <stpeter> ermine: I've started to process XEP-0060 errata so I will look at that here soon
[11:05:47] <ralphm> my example 128 doesn't have a form
[11:05:54] <ermine> excellent
[11:06:02] <ralphm> i.e. the one on the xmpp.org site
[11:07:04] <ermine> heh
[11:07:09] ermine refreshed
[11:07:14] <stpeter> sorry about that
[11:07:23] <stpeter> I mistakenly generated an interim version
[11:07:38] <ermine> it was node creation form
[11:08:06] <ermine> 127
[11:09:58] <ermine> btw, pubsub#meta-data specifies pubsub#contact, whis is filled nowhere
[11:12:49] <ermine> s/whis/which/
[11:13:45] nabatt joins the room
[11:14:58] Florob leaves the room
[11:15:50] Florob joins the room
[11:16:14] Florob leaves the room
[11:16:36] Florob joins the room
[11:17:38] teo leaves the room: Replaced by new connection
[11:17:42] teo joins the room
[11:18:45] Kev joins the room
[11:20:30] <ermine> stpeter: also, the example 127 does not show how you can specify *your* roster groups for access model "roster"
[11:21:02] <ermine> i dont understand, are there only predefined roster groups or any groups
[11:21:03] <stpeter> ermine: ok, I'll look at that in a minute :)
[11:22:48] jack leaves the room
[11:23:02] nabatt leaves the room
[11:23:38] nabatt joins the room
[11:23:55] ermine waits happily
[11:27:21] <stpeter> ok, I got all my inboxes back down to zero :)
[11:32:17] <stpeter> brb
[11:38:10] <ralphm> one, no?
[11:38:42] <stpeter> 2 inboxes at zero, one at 1 :)
[11:38:46] <ralphm> :-)
[11:38:59] <ralphm> stpeter: did you read my comment on disco publishing?
[11:39:16] <stpeter> I have a WebEx account, a Gmail account (forwards from my old jabber.org account), and stpeter.im
[11:39:24] <stpeter> ralphm: processing now
[11:42:30] <stpeter> hmph, too many interruptions this morning
[11:42:43] stpeter scrolls up
[11:42:48] Kiwi leaves the room
[11:43:03] <ermine> kill inbox
[11:44:45] Kiwi joins the room
[11:46:39] <stpeter> ok "<ermine> stpeter: hi, isn't it a typo in example 128 of xep 60 -- there is no <value/> element in the latest <field/> in that example?"
no, that's not a typo because it just happens that there is no default value for that field (see XEP-0004)
[11:47:23] <ermine> okay
[11:47:25] <stpeter> "<ermine> stpeter: also, the example 127 does not show how you can specify *your* roster groups for access model "roster""
fixed, I added that to Example 133 in my working copy
[11:47:53] <stpeter> ermine: you can't add a roster group by modifying the node configuration form
[11:48:04] <stpeter> so the server tells you what your groups are, and you choose from those
[11:49:30] <stpeter> ermine: there is an instance of pubsub#contact in Example 18
[11:50:12] <stpeter> ralphm: I hadn't seen that creative use of pubsub meta-data w.r.t. disco publish :)
[11:50:39] <ermine> stpeter: how are you going to fill contact field?
[11:50:56] Christian leaves the room
[11:51:11] js joins the room
[11:51:15] <stpeter> ermine: http://xmpp.org/extensions/xep-0060.html#example-18 says:
<field var='pubsub#contact' label='People to contact with questions'>
<value>bard@shakespeare.lit</value>
</field>
[11:51:41] <ermine> oh, i got about roster groups
[11:52:13] <stpeter> ah:
<field var='pubsub#access_model'><value>roster</value></field>
<field var='pubsub#roster_groups_allowed'>
<value>friends</value>
<value>servants</value>
<value>courtiers</value>
</field>
[11:52:22] <ermine> it *shows*, it is not editing form, right?
[11:52:39] jack joins the room
[11:52:54] <stpeter> that is the form submission from Example 133
[11:52:54] <ermine> probably i'm dumb today
[11:53:04] <stpeter> http://xmpp.org/extensions/xep-0060.html#example-133
[11:53:14] <stpeter> but I changed it in my working copy
[11:53:47] <stpeter> and the change is what I posted a minute ago
[11:54:47] <ermine> stpeter: does it mean that you can mix all pubsub#* fields in various forms?
[11:55:10] <ermine> pubsub#create_node ns, pubsub#meta-data ns
[11:55:15] <stpeter> no
[11:55:20] <ermine> and so on
[11:55:50] <stpeter> the pubsub#roster_groups_allowed field is for the node_config form
[11:55:53] <ermine> weird
[11:56:45] <ermine> oh i meant node_config
[11:57:35] <ermine> then node_config does not include contact field
[11:57:40] <ermine> right?
[11:58:27] <stpeter> not yet :)
[11:58:54] darco joins the room
[11:59:08] remko joins the room
[11:59:25] <ermine> it was that i wanted to say...
[11:59:59] <stpeter> ah ok
[12:00:10] <stpeter> yes it needs to be in node_config, too
[12:00:43] <stpeter> or maybe it does :)
[12:01:05] Flo joins the room
[12:01:08] <stpeter> yes, I think it does
[12:01:57] ermine shrugs -- it is always a problem when one set looks as a subset of another set
[12:02:56] <stpeter> yes
[12:04:10] <ermine> for today it is all, thanks
[12:04:13] <stpeter> ok
[12:04:23] <stpeter> next I will process some emails from Brett Zamir :)
[12:09:47] steve-e joins the room
[12:11:17] <ralphm> stpeter: but do you like it?
[12:14:50] Christian joins the room
[12:16:08] ralphm2 joins the room
[12:16:56] Flo leaves the room
[12:18:12] <stpeter> ralphm: not sure about that yet :)
[12:19:03] johnny leaves the room
[12:21:50] jkhii joins the room
[12:32:15] mlundblad joins the room
[12:42:42] <stpeter> Tobias: so I suppose that I need to write an agenda :)
[12:43:11] <stpeter> Tobias: what would you like to discuss? :)
[12:44:27] jack leaves the room
[12:45:42] <Tobias> stpeter: state of current pubsub/PEP implementations? bidirectional XMPP Streams for S2S over one socket with backwards compatibility, process of XSF's server migration to the new version of the OS :)
[12:45:44] <Tobias> just for starters ;)
[12:46:08] Lega leaves the room
[12:46:29] jeti joins the room
[12:49:40] r000n joins the room
[12:53:40] <stpeter> heh ok
[12:54:19] Kiwi leaves the room
[12:58:42] darco leaves the room: a
[13:00:55] <stpeter> yay http://identi.ca/notice/3434288
[13:02:08] johnny joins the room
[13:02:09] <MattJ> Congratulations indeed :)
[13:02:29] <Kev> Thanks :)
[13:03:03] <stpeter> MattJ: did Kev ops you in #jabber?
[13:03:34] <MattJ> I only joined it today, didn't realise it was opened already (last time I tried it was locked)
[13:03:40] <Kev> stpeter: I think you have to give him permaops by chanserv.
[13:03:46] <stpeter> ok
[13:03:47] <Kev> I can give ops temporarily.
[13:03:50] <stpeter> ah
[13:03:51] <stpeter> ok
[13:04:03] stpeter sshes to apollo and fires up irssi
[13:04:06] <MattJ> Yes, they haven't invented permanent affiliation yet :)
[13:04:25] MattJ looks around for an IRC-person about to jump on him
[13:07:01] stpeter looks up the appropriate IRC commands
[13:07:18] <MattJ> Good luck :)
[13:07:24] <stpeter> yeah
[13:07:56] <MattJ> niekie probably has a good idea, he runs an IRC server
[13:10:09] wiretap leaves the room
[13:10:19] wiretap joins the room
[13:10:28] <stpeter> I did it yesterday for Kev
[13:11:35] <stpeter> ok I did '/msg ChanServ FLAGS #jabber MattJ +O'
[13:11:51] <MattJ> k
[13:12:02] <stpeter> +O - Enables automatic op.
[13:12:10] <MattJ> Seems to work, thanks :)
[13:13:40] <stpeter> Tobias: "bidirectional XMPP Streams for S2S over one socket with backwards compatibility" is a big topic :)
[13:13:48] <stpeter> Tobias: I think we need more preparation for that one
[13:14:07] <stpeter> brb, need to heat up some lunch
[13:16:58] wiretap leaves the room
[13:17:04] wiretap joins the room
[13:17:18] bct joins the room
[13:18:27] bct leaves the room
[13:20:46] <Kev> http://www.amazon.co.uk/XMPP-Definitive-Real-Time-Applications-Technologies/dp/059652126X/ref=sr_1_1?ie=UTF8&s=books&qid=1239733146&sr=8-1 Thinks It'll be published 4th May. Looking forward to it :)
[13:21:12] <Tobias> stpeter: big topic? it's like it should have always worked imo...do you know any other protocol that uses two TCP connections to talk bidirectional between two host?
[13:21:30] <Kev> Tobias: ftp :)
[13:21:58] <Tobias> Kev: only for file transfers
[13:22:05] <Tobias> on for browsing around
[13:22:09] <Tobias> *not
[13:24:23] <stpeter> Tobias: the unidirectional streams were for dialback because that supplies only weak identity verification in one direction
[13:24:50] <stpeter> Kev: ah, cool, it's good to have some sort of date :)
[13:24:59] stpeter checks amazon.com in the USA
[13:25:20] <Tobias> stpeter: sure it originated there...but still...it's kinda hacky
[13:25:47] <stpeter> yes, May 4 in the States, as well
[13:25:55] remko checks belgium
[13:26:09] <remko> i suspect it'll be out here tomorrow or so
[13:26:39] <Tobias> and with *real* identity verification like certificates is different anyway
[13:26:45] <stpeter> Tobias: *but* I thought you were talking multiplexing domains over the same TCP connection
[13:26:55] dragonlelo joins the room
[13:27:15] johnny leaves the room
[13:27:29] <Tobias> stpeter: of course that would be nice too :)
[13:27:58] <stpeter> Tobias: and that's a harder problem
[13:28:09] <Tobias> sure that's a bit harder
[13:28:30] <stpeter> I've been talking with some IETF people about that
[13:29:16] <Tobias> and?
[13:29:25] <stpeter> no conclusions yet
[13:29:50] <stpeter> I've promised to write up a problem statement with Joe Hildebrand to clearly define the problem
[13:29:59] <Tobias> heh...IETF wheels are rotating slower than XSF ones ;)
[13:30:11] <stpeter> :P
[13:30:18] <stpeter> always
[13:30:23] <stpeter> why do you think we have the XSF?
[13:31:06] bct joins the room
[13:31:35] <Tobias> stpeter: can't be for the member meetings at fancy places like hawaii or bahamas ;)
[13:32:52] <stpeter> true :)
[13:32:56] bct leaves the room
[13:33:08] <stpeter> although IETF meetings are not held in places like that
[13:33:21] <stpeter> you're thinking of Liberty Alliance and groups of that kind
[13:33:30] <Tobias> Liberty Alliance?
[13:33:49] <stpeter> for-pay standards group
[13:33:57] <Tobias> sounds like something which is for sure not for liberty :D
[13:35:37] <ermine> stpeter:did you notice that in that example of node_config you cannot see which roster groups you've selected before?
[13:35:58] ermine heavily implementing node_config
[13:36:11] <Tobias> stpeter: you must admit that it gives a strange user experience being able to be talked to but not being able to talk to someone
[13:36:30] <ermine> jabber is poor stuff
[13:37:29] <stpeter> ermine: feel free to work on some other technology
[13:37:36] huni joins the room
[13:37:51] <stpeter> ermine: the pubsub server can indicate that information in the form
[13:37:59] <stpeter> ermine: standard XEP-0004 stuff
[13:38:00] <stpeter> brb
[13:38:06] <ermine> stpeter: but how i can mark that the list item is marked?
[13:38:08] <ermine> :)
[13:39:07] <ermine> no word "selected" in xep 04
[13:42:28] <ermine> well, if i can insert multiple <value/>, it is not a problem
[13:42:34] <ermine> for list-multi
[13:42:55] <stpeter> sure you can
[13:43:24] <stpeter> see http://xmpp.org/extensions/xep-0004.html#example-2
[13:43:40] <stpeter> for example:
<field type='list-multi'
label='What features will the bot support?'
var='features'>
<option label='Contests'><value>contests</value></option>
<option label='News'><value>news</value></option>
<option label='Polls'><value>polls</value></option>
<option label='Reminders'><value>reminders</value></option>
<option label='Search'><value>search</value></option>
<value>news</value>
<value>search</value>
</field>
[13:45:02] <ermine> well, i prefer strong description, not examples, because examples can have typos
[13:46:22] <stpeter> ermine, please read the specifications, do you think I write them just for the fun of it?!?!?!?!??!
<value/> -- The XML character data of this element defines the default value for the field (according to the form-processing entity) in a data form of type "form", the data provided by a form-submitting entity in a data form of type "submit", or a data result in a data form of type "result". In data forms of type "form", if the form-processing entity provides a default value via the <value/> element, then the form-submitting entity SHOULD NOT attempt to enforce a different default value (although it MAY do so to respect user preferences or anticipate expected user input). Fields of type list-multi, jid-multi, text-multi, and hidden MAY contain more than one <value/> element; all other field types MUST NOT contain more than one <value/> element.
http://xmpp.org/extensions/xep-0004.html#protocol-field (bullet point 3)
[13:46:40] <ermine> flood!
[13:46:57] <stpeter> Tobias: speaking of which, that would be better as <dl>
[13:48:20] <Tobias> stpeter: yep...that's what dls ar for
[13:48:20] <Tobias> :)
[13:48:46] <stpeter> fixing now
[13:49:23] <ermine> stpeter: do you know all 300 xeps by heart?
[13:50:05] <stpeter> Tobias: reload http://xmpp.org/extensions/xep-0004.html#protocol-field
[13:50:31] <stpeter> ermine: no, only the ~20 XEPs that are really important
[13:51:40] <ermine> stpeter: which ones? i guess 04, 30, 60, all old iqL* namespaces, ...
[13:51:46] r000n leaves the room
[13:57:47] jack joins the room
[13:58:35] dirk joins the room
[13:58:52] <stpeter> it seems that perhaps our meeting starts in 2 minutes? :)
[13:59:09] <stpeter> I think I put the wrong time in the XSF calendar
[13:59:14] <dirk> looks like it. And "Hi everyone"
[13:59:16] <remko> where was that again?
[13:59:19] <remko> is it here?
[13:59:19] <stpeter> (stupid DST)
[13:59:24] <stpeter> hi dirk!
[13:59:25] <stpeter> brb
[13:59:52] <Tobias> steve-e: my ical sas we got one hour to go
[13:59:59] <Tobias> *stpeter
[14:00:05] <Tobias> *says
[14:01:29] <stpeter> Tobias: yes, my fault
[14:01:50] <Tobias> heh
[14:02:14] <Tobias> i synced the calendars with my mobile however my mobile doesn't care about timezones :D
[14:02:20] <stpeter> I think we need to have more focused meetings, so I'm sorry about the lack of an agenda
[14:02:26] <Tobias> it alarmed one hour ago :)
[14:02:45] <stpeter> I never even wrote up the minutes for the last meeting :(
[14:02:48] dirk is coding something for freevo right now and is also fighting with time zones and the lack of support of them sometimes
[14:03:06] <stpeter> so shall we start?
[14:03:26] bct joins the room
[14:03:53] <stpeter> dirk: do you have any further thoughts about e2e encryption? I think the discussions at IETF 74 were interesting, but they didn't change my thinking about "XTLS"
[14:04:17] <stpeter> we can't optimize for every case (e.g., offline messages)
[14:05:37] <dirk> like discussed on the list, I think offline is a different use case. Trying to fit everything into one protocol seems to be a bad idea. I you want offline messages, you could encrypt them with the public key in the certificate or exchange a key over XTLS first
[14:06:02] <stpeter> "Trying to fit everything into one protocol seems to be a bad idea." -- agreed!
[14:06:18] stpeter has set the subject to: Monthly XMPP Meeting | Jabber/XMPP Development | Logs: http://logs.jabber.org/jdev@conference.jabber.org/
[14:06:22] Astro joins the room
[14:06:27] Florob leaves the room
[14:06:44] dwd joins the room
[14:06:45] <dirk> What is the topic for today? I don't remember reading about it
[14:07:33] <stpeter> dirk: that's because I didn't define a topic
[14:07:34] waqas joins the room
[14:07:44] <stpeter> my bad
[14:08:02] <dirk> that explains it
[14:08:02] stpeter is stealing topics from http://xmpp.org/xsf/roadmap.shtml :)
[14:08:09] <Tobias> heh..just found out i forgot to tell my mobile phone the timezone it's in :) now it shows the time correctly :D
[14:08:15] <dwd> The topic is, therfore, implementation-defined.
[14:08:47] <dwd> Which, presumably, means we all talk about different things, and ignore what anyone else says.
[14:08:54] niekie joins the room
[14:08:55] <stpeter> dwd: you do that anyway
[14:08:55] <dwd> So, same as last month, then. ;-)
[14:09:18] <niekie> *enters lurk mode*
[14:09:24] <dwd> stpeter, Hey - *I* do the snarky comments around here.
[14:09:30] Florian joins the room
[14:09:34] <stpeter> perhaps it would be good to mention the current Last Calls
[14:09:39] MattJ feeds dwd some bacon to keep him quiet
[14:09:46] ermine 'd hidden in the corner and looks
[14:10:03] MattJ is doing boring packaging stuff
[14:10:05] dwd is cooking fish chilli. Or chilli'd fish.
[14:10:32] dirk is getting hungry reading what dwd is doing
[14:10:41] <stpeter> we issued a second Last Call on http://xmpp.org/extensions/xep-0232.html (Software Information)
[14:11:01] <stpeter> I think some people didn't like the use (misuse) of disco / data forms for that?
[14:11:21] <stpeter> data forms is defined for this kind of "extended disco" stuff via XEP-0128
[14:11:46] <stpeter> it's just more angle brackets IMHO
[14:11:57] <dirk> I just wondered why we use data forms for something like this
[14:11:58] <MattJ> Yeah, that's the problem :P
[14:12:04] <Tobias> dwd: i guess with bacon right ;)
[14:12:22] <stpeter> dirk: because that's what http://xmpp.org/extensions/xep-0128.html says we're supposed to do :)
[14:12:25] <dwd> I worry about whether we're reducing XEP-0115 cache effectiveness, but people seem to want this stuff, so...
[14:12:33] <stpeter> dwd: yes, I worry about that, too
[14:12:59] <dwd> Tobias, Astonishingly, no pigs were harmed in the making of this meal.
[14:13:02] <MattJ> I think we've already reduced it too much
[14:13:17] <stpeter> IMHO the caching is more important than this kind of extension, but hey...
[14:13:20] <stpeter> MattJ: how so?
[14:13:22] <dwd> MattJ, The name is already in, yes.
[14:13:39] <Tobias> stpeter: what are you talking about?
[14:13:40] <MattJ> Well I think too many things are put into disco without consideration for caps
[14:13:47] <Tobias> what changes do people want in entity caps?
[14:13:52] <ermine> dwd: catch only caps'ed people, ignore all others
[14:13:53] <MattJ> But where we draw the line is arbitrary :)
[14:14:05] <Tobias> which reduce cache efficiency
[14:14:30] <stpeter> Tobias: I'm talking about forcing software information (XEP-0232) into service discovery results, thus reducing the effectiveness of the entity capabilities caches (or making them much bigger and therefore harder to search through)
[14:14:49] <dwd> MattJ, I would like to get rid of all client-specific things from the XEP-0115 hash, truth be told. But maybe we're too far down that route.
[14:14:51] <remko> it sounds attractive
[14:14:58] <remko> but i think it's not worth it
[14:15:02] <stpeter> remko: it = ?
[14:15:09] <remko> stuffing software info in 232
[14:15:13] <dwd> stpeter, it == bacon?
[14:15:13] <stpeter> ah
[14:15:23] <remko> it's attractive if there are clients out there who want to display the client version at all times
[14:15:29] <MattJ> dwd, if "client-specific" == configurable options then I agree
[14:15:41] <MattJ> but like I said, the line is not clear-cut
[14:15:43] <remko> which, IMO, is something you only need on request, but many users disagree with me on this one
[14:15:45] <dwd> MattJ, Implementation specific, perhaps is a better term.
[14:15:52] <stpeter> remko: right
[14:15:54] <Tobias> yeah....that's a bad idea...since entity capabilities, like the name suggests, is about the capabilities/features of a client or server, and being version 1.0 instead of 1.1 isn't actually a feature :)
[14:16:03] <dwd> remko, I wonder whether those users are a vocal minority, though.
[14:16:04] <Tobias> just meta data
[14:16:05] <remko> i guess it's more of the the voyeurist thing in people that's getting popular
[14:16:09] <Tobias> without functional meaning
[14:16:11] <remko> dwd: quite possibly so
[14:16:38] <remko> personally, i think that with the current disco, you know enough, being client name
[14:16:41] <remko> version and os shouldn't be there anyway
[14:16:57] <dwd> remko, I mean, it's not something that achieves anything. And if it's really important, it could be done using a distinct "client version hash", which I'd be perfectly happy with.
[14:16:59] <remko> and i hope that over time, all these details will disappear soon. Maybe it could be a pep thing, dunno.
[14:17:09] <remko> i would say it's more PEP than disco
[14:17:13] <dwd> remko, C2C PEP, of course.
[14:17:15] <MattJ> Well servers now have to store a caps table which increases in size with each new XEP using disco (or PEP node to +notify on)
[14:17:39] <remko> dwd: why c2c? Isn't sub-based enough?
[14:17:39] <stpeter> dwd: with compression, sure
[14:17:47] <Tobias> MattJ: servers have to store caps table?
[14:17:57] <MattJ> Tobias, they do, if they want to support PEP at least
[14:18:03] <dirk> C2C PEP is something I have on my todo list, too. But for a different pupose.
[14:18:42] <MattJ> Tobias, they also have to intercept presence and actively disco people
[14:19:00] <Tobias> MattJ: i thought this was optional
[14:19:18] <stpeter> remko: so basically you're suggesting a PEP node for jabber:iq:version, i.e., http://xmpp.org/extensions/xep-0092.html
[14:19:33] <MattJ> Tobias, sure, you could disco on nearly every presence stanza received, but I really don't think that's a sensible option :)
[14:20:36] <dwd> remko, Because PEP isn't client-specific, so you'd want a client-specific variant on PEP, which is simplest done by having the client implement it.
[14:21:03] <stpeter> dwd: or have a "resources" pep node...
[14:21:07] <dwd> remko, Simplest architecturally, I mean. It does force client developers to implement a PEP service, but I have no sympathy on that front. :-)
[14:21:29] piers joins the room
[14:21:33] <dwd> stpeter, Ew. But yes, that could be done - publish node-ids associated with resource strings, or some such.
[14:21:36] <stpeter> at that point people will simply use XEP-0092
[14:21:37] <Tobias> MattJ: another point to get software name and version out of the hash input
[14:21:47] <MattJ> Tobias, exactly :)
[14:22:05] <stpeter> ok
[14:22:07] <Tobias> MattJ: what are the arguments for integrating it?
[14:22:08] <MattJ> Tobias, but name and version isn't half as bad as all the other stuff
[14:22:12] <stpeter> I think that's enough on this topic
[14:22:12] <dirk> It is more or less simple to implement a PEP service if the only client allowed to publish is the client itself. It more or less is only publish
[14:22:28] <stpeter> we could talk about this for hours :)
[14:22:37] <stpeter> the Council will be voting on this next week
[14:22:48] MattJ nods
[14:22:52] <Tobias> stpeter: then i talk to matt in private if you don't want...pft...bla...tztztz ;)
[14:22:53] <stpeter> I might vote -1 :)
[14:23:12] MattJ rolls his eyes
[14:23:19] <stpeter> we also have a Last Call on roster versioning http://xmpp.org/extensions/xep-0237.html
[14:23:33] <stpeter> MattJ: have you tested Prosody's implementation with Lampiro?
[14:23:34] <dwd> Tobias, Speak on the list, or forever hold thy peace.
[14:23:37] <MattJ> I'm happy with roster versioning
[14:23:40] <MattJ> But no, no testing yet
[14:23:44] <stpeter> MattJ: ok
[14:23:48] MattJ pokes ff while it is on his mind :)
[14:23:58] <stpeter> MattJ: it's probably easier for Fabio to test
[14:24:07] <dwd> I need to look at this empty roster case. I think it's quite interesting, and may have a problem there.
[14:24:16] <stpeter> dwd: yes
[14:24:22] <Tobias> dwd: yeah...just because we have ugly archive interface we must not flee into the SMTP world everytime
[14:24:31] <dwd> All the other cases raised turn out, much to my surprise, to be non-issues.
[14:25:16] <stpeter> dwd: agreed
[14:26:15] <stpeter> dwd: I'll publish an updated version of the roster versioning XEP soon
[14:26:24] <stpeter> interim last call version or whatever
[14:26:30] <stpeter> with more examples
[14:26:40] <dwd> Roster Versioning: The Story So Far.
[14:26:46] <stpeter> :)
[14:27:47] <stpeter> dwd: perhaps the empty roster case is solved if the server includes a flag that says "pushes on the way"
[14:28:15] <dwd> stpeter, No, you want to include a flag that says "This is the complete roster".
[14:28:27] <dwd> stpeter, Optimize for the common case, and all.
[14:28:40] <stpeter> right, that's better
[14:28:49] <dwd> But to tell the truth, I don't know yet whether this is really a problem.
[14:28:53] <stpeter> ok
[14:28:59] <dwd> I kind of suspect it is, though.
[14:29:03] <stpeter> you think about it some more, and I'll do the same :)
[14:29:03] <MattJ> Like I said on the list, I don't think it is
[14:29:20] <MattJ> But I'm happy to be corrected by dwd's thinking :)
[14:29:21] <stpeter> edge cases are fun :P
[14:29:24] <stpeter> ok
[14:29:26] <stpeter> moving on
[14:29:52] <stpeter> the other Last Last Last Calls right now are for Jingle, but no feedback yet -- I think people are Jingled out :)
[14:30:49] <dirk> stpeter: jingle is a bit more complicated than the other two
[14:31:04] <stpeter> dirk: for sure :)
[14:31:07] <dirk> I can only say something about 0166 and I like it as it is
[14:31:41] <stpeter> dirk: the Jingle Thingle exposed some issues and those are all incorporated into the text
[14:32:31] <stpeter> now we just want to make sure that everyone agrees with those fixes
[14:32:45] <dwd> My gut feeling is that it's good enough for Draft, basically.
[14:34:12] <dwd> I'm going to bow out now - food's ready.
[14:36:12] <stpeter> ok
[14:36:25] <stpeter> Tobias: what were your issues?
[14:36:39] <stpeter> (sorry, just moved to a different physical room so I got lost there for a few minutes)
[14:36:47] <MattJ> stpeter, you'll regret asking that :)
[14:36:59] <stpeter> heh
[14:37:07] <Tobias> okay..here i go.... :D
[14:37:20] <stpeter> <Tobias> stpeter: big topic? it's like it should have always worked imo...do you know any other protocol that uses two TCP connections to talk bidirectional between two host?
[14:37:26] <stpeter> ah, wrong one
[14:37:40] <Tobias> though nice quote
[14:37:41] <stpeter> <Tobias> stpeter: state of current pubsub/PEP implementations? bidirectional XMPP Streams for S2S over one socket with backwards compatibility, process of XSF's server migration to the new version of the OS :)
[14:38:22] <Tobias> are there any other known pubsub implementations beside idavoll and ejabberd?
[14:38:42] <MattJ> Tigase?
[14:39:04] <Tobias> right
[14:39:11] <MattJ> Possibly Openfire too
[14:39:25] <Tobias> interesting :)
[14:39:28] <stpeter> hmm, Openfire :)
[14:39:30] <Tobias> didn't know openfire has that
[14:39:43] <stpeter> it was a Summer of Code project IIRC
[14:39:44] <MattJ> I think they have PEP, so I'm assuming they have pubsub
[14:40:01] <Tobias> okay...thanks...nice to know
[14:40:18] <stpeter> I think we need a PubSub Pub to follow up on the Jingle Thingle
[14:40:32] <MattJ> +1 :)
[14:40:34] <dirk> +1
[14:40:48] MattJ will hopefully have implemented it by then
[14:40:57] <Tobias> MattJ: i hope for you too
[14:41:21] <MattJ> I need it, at least for PEP :)
[14:41:32] <Tobias> i need it more :)
[14:41:42] <Tobias> stpeter: what on the last point of mine?
[14:41:49] <ermine> seems nobody hopes for me
[14:42:00] <MattJ> ermine, what language are you coding in?
[14:42:09] <Tobias> MattJ: the magical one ;)
[14:42:12] <stpeter> Tobias: we'll need to ping Jonathan Siegle about that
[14:42:14] <ermine> MattJ: erlang, indeed
[14:42:22] <MattJ> ermine, then hope is lost on you :)
[14:42:39] <Tobias> stpeter: i can ping him...i don't have his jid :P
[14:42:47] <Tobias> *can't
[14:42:59] <MattJ> but luckily erlang comes with hope as an optional add-on
[14:43:26] <stpeter> Tobias: he has multiple JIDs, I think siegle at jabber dot org
[14:43:30] <ermine> MattJ: how are you going to integrate pep on lua with any server?
[14:43:37] <dwd> Tobias, We do PEP, although the engine itself is capable of a bit more than just PEP.
[14:43:44] <MattJ> ermine, what do you mean?
[14:43:59] <Tobias> dwd: for my current project i mostly need pubsub
[14:44:00] <MattJ> dwd, same plans here :)
[14:44:07] <ermine> MattJ: it requirs to process presence and roster stuffs
[14:44:23] <MattJ> ermine, I can handle that (though I believe it to be very "icky" :) )
[14:45:11] <ermine> MattJ: i guess using filtering all packets?
[14:45:35] <MattJ> ermine, just presence, no?
[14:45:59] <MattJ> if I have to filter anything else then PEP is even worse than I thought :P
[14:46:31] <ermine> MattJ: then you'll have to process subscription states online, too
[14:46:39] <MattJ> Sure
[14:46:43] Treebilou leaves the room
[14:46:51] <ermine> not easy job
[14:46:54] <dwd> MattJ, You have to filter the Nameless Stanzas Of Doom, too.
[14:46:59] <stpeter> well, for one thing, we really need to deploy PEP at jabber.org....
[14:47:05] <MattJ> ermine, er... why? :)
[14:47:09] <MattJ> ermine, we do it already
[14:47:58] <MattJ> dwd, are they like whacks, but even more nameless?
[14:48:12] <ermine> MattJ: each pubsub request requirs 5-10 (in average) sql requests
[14:48:18] <dwd> MattJ, Way worse. Zero-length, too.
[14:48:26] <MattJ> ouch
[14:48:32] <dwd> ermine, Ah, SQL, Schmeequal.
[14:48:41] <ermine> i hope to optimize it using pl/sql procedures
[14:48:58] <MattJ> ermine, 5-10?
[14:48:59] <dwd> ermine, Try mapping your PubSub engine onto an X.500 DSA, then you can tell me you've lived. :-)
[14:49:52] <ermine> MattJ: check if node exists, fetch its config, check affiliation/subscription stuff for requester, commit publication/whatever
[14:50:50] <ermine> pubsub is very hard service
[14:50:52] <dwd> ermine, Just load in the node-state once.
[14:51:12] <MattJ> dwd, but this is erlang :P
[14:51:22] <ermine> dwd: cache?
[14:51:26] <dwd> ermine, You'll only cost in memory, you'll save massively in I/O and CPU, and the only downside is that DBAs can't fiddle with the PubSub nodes behind the xmppd's back.
[14:51:42] <dwd> ermine, And that last is an advantage, to most non-DBAs. :-)
[14:51:55] TuX leaves the room
[14:52:28] <ermine> dwd: i'm going to use various caches at last development stage
[14:52:55] <ermine> after pl/pgsql stuff
[14:53:13] <dwd> ermine, No, not cache. Just don't bother going to the store more than once. Treat the SQL database as a store, not the master copy.
[14:53:43] <stpeter> I have another topic I'd like to bring up -- stream management (XEP-0198) -- are people happy with where we are today?
[14:53:47] <dwd> Actually, what am I saying?
[14:54:07] <MattJ> stpeter, it appears so, I'm looking forward to implementing :)
[14:54:10] <ermine> dwd: it is right
[14:54:25] <MattJ> and dwd managed to convince me that it is worth implementing for s2s also
[14:54:28] <dwd> ermine, No, no, just really make it depend on a tightly coupled SQL layer. It's really important to, erm, do stuff with SQL. Lots. Really slowly.
[14:54:28] <ermine> dwd: but how many virtual nodes i can keep in memory?
[14:54:49] <dwd> ermine, None, you're so right. Slower is better. *nods*
[14:55:01] <dwd> ermine, For me, anyway. ;-)
[14:55:03] <MattJ> dwd, did you know that when privacy lists are stored in an external DB ejabberd makes an SQL query for almost every stanza? :)
[14:55:12] <MattJ> it did at least the last I knew :)
[14:55:31] <dwd> MattJ, And this is the correct way of doing it. For ejabberd, anyway. :-)
[14:55:37] <MattJ> Agreed
[14:55:49] MattJ gives dwd the handshake
[14:56:01] <ermine> dwd: you said before that caps (xep 115) cashe should be reduces, so why it is too large for you?
[14:56:30] <dwd> ermine, I/O, network lookups - not memory.
[14:57:09] <ermine> dwd: i made my caps module which keeps info only those people who present caps in their presence, i guess it is not large
[14:57:41] <dwd> ermine, You purge them when they fall offline?
[14:58:12] <ermine> no, why?
[14:58:26] teo leaves the room: Replaced by new connection
[14:58:37] teo joins the room
[14:58:42] <dwd> ermine, Just wondered. I considered this to give it an upper bound, but decided it was silly.
[14:58:45] ermine didnt considered this case yet
[14:59:13] <dwd> ermine, But we don't collect statistics on how big that cache gets, it's just the numbers of disco#info queries I want to keep down.
[14:59:51] <dwd> ermine, Aside from anything else, every time I see "Disco Query", some 70's tune pops into my head.
[15:00:16] <stpeter> so we've been chatting for 60 minutes now
[15:00:22] <dwd> ermine, I can barely type it without typing "Get down, get down". It's driving me mad.
[15:00:34] <dwd> I did want to mention the bidirectional S2S thing.
[15:01:01] <stpeter> (BTW, I think there is value in talking about things that are in Last Call)
[15:01:07] <stpeter> dwd: fire away
[15:01:17] <dwd> I have this long-standing idea for blatant miuse of XEP-0220 for S2S optimization, basically.
[15:01:22] <ermine> dwd: will you change the "ver"?
[15:01:50] Yota_VGA joins the room
[15:02:03] <ermine> if you're simply flying, the ver does not change, there is no job
[15:02:24] darco joins the room
[15:02:30] <dwd> Bidi is one aspect of this that I've not quite figured out, but I assume we can do it by signalling the possibility in a stream feature, and then offering in an extended <db:result/>
[15:02:31] <stpeter> hi darco
[15:02:34] <ermine> the job is only when you attemtp to invalidate disco response, so i merely omitted it
[15:02:41] <darco> Howdy
[15:02:55] <dwd> ermine, Change the ver? I don't see what you mean.
[15:03:25] <ermine> dwd: the caps attribute "ver"
[15:03:47] <dwd> ermine, Yes, but that's our lookup key.
[15:03:50] <ermine> dwd: probably i'm dumb today, nevermind
[15:04:22] <dwd> ermine, Ah. I see. Yes, you could implement it that way. But we don't. :-)
[15:04:25] darco leaves the room
[15:04:36] <ermine> dwd: i meant when you're simply go online/offline/online, you wont change the ver value, right?
[15:05:07] <stpeter> dwd: as I mentioned to Tobias, the bigger challenge is to figure out how to multiplex domains across the same stream (and to do it securely)
[15:05:18] <ermine> but i need now consider when to purge data
[15:05:19] <dwd> stpeter, Also via XEP-0220.
[15:05:57] <dwd> stpeter, You just don't bother doing the dialback, as there's no point doing so if you can validate the domain via the certificate. The tricky bit is when you need multiple certificates on the same stream.
[15:06:02] <stpeter> dwd: how do we make progress on this?
[15:06:14] <stpeter> dwd: right, Joe and I talked with ekr about that at IETF 74
[15:06:20] <dwd> stpeter, We could use xml-dsig on the <db:result/> for that, I suppose.
[15:06:47] <dwd> stpeter, Although dsig scares lots of folk. And Ekr will freak out because it's not in the TLS layer.
[15:07:07] MattJ will too :)
[15:08:10] <stpeter> dwd: personally I would prefer to leave dialback behind...
[15:08:26] <MattJ> Note that there are some things in favour of dialback
[15:08:54] <MattJ> Being able to delegate to another physical location (though you can do this with TLS)
[15:09:04] <MattJ> and checking that servers aren't running behind a NAT
[15:09:14] <stpeter> I think we need to have a meeting just about this topic
[15:09:18] <dwd> stpeter, That actual dialling back bit could be. But there's lots of optimizations and trickery that can be done, and mostly, it's just a convenient base syntax to build on.
[15:09:40] <stpeter> (perhaps the Monthly XMPP Meeting will become the Fortnightly XMPP Meeting)
[15:09:56] <MattJ> I'd love a discussion on improving s2s
[15:10:06] <dwd> stpeter, I did promise fippo - whom I've had a few exchanges with on this subject - that I'd write an update to XEP-0220 to cover the various immediate optimizations that can be done.
[15:10:13] <MattJ> Because waqas and I are too tempted to do something non-standard between Prosody instances :)
[15:10:22] <dwd> stpeter, If you name a date, I'll endeavour to have something written up by then.
[15:10:54] <dwd> MattJ, Do so, as long as you document, it'll be valuable experience.
[15:11:23] <MattJ> That's what I keep telling myself :)
[15:11:56] <stpeter> dwd: how about May 5?
[15:13:07] <dwd> stpeter, I sinscerely hope to have this release out the door by then. :-)
[15:13:13] <stpeter> :)
[15:13:45] <dwd> MattJ, Can you write up your ideas by then?
[15:14:11] <MattJ> dwd, sure
[15:15:40] <stpeter> so I'll send out a mail about this because yes we need to figure it all out, perhaps as part of the xmppbis efforts
[15:16:13] <niekie> MattJ, IPX?
[15:16:24] <niekie> (Inter-Prosody eXchange? :-P)
[15:16:37] <dwd> niekie, Ah! I thought you meant IPX/SPX.
[15:16:40] <MattJ> stpeter, XMPP 1.2? 2.0? :)
[15:16:53] <stpeter> 1.1 at most, please :P
[15:16:55] <niekie> We definitely need 2.0! Else we won't be cool anymore :(
[15:17:00] <niekie> *grins*
[15:17:16] MattJ waits for XMPP 3.0: Semantic IM
[15:17:38] <stpeter> XMPP = Web 3.0
[15:17:43] <MattJ> :P
[15:17:50] <stpeter> ok
[15:18:00] <stpeter> are there any other topics we want to discuss?
[15:18:36] <MattJ> I can't think of anything
[15:18:58] <stpeter> I think it will be very productive to have a discussion about s2s
[15:19:02] <MattJ> waqas, around?
[15:19:29] <MattJ> Agreed
[15:19:30] <dwd> We should also discuss porn and spam over XMPP. The other popular protocols have them, it could be a serious adoption driver.
[15:20:16] <stpeter> dwd: that's XXXMPP
[15:20:42] <stpeter> ok so I will schedule the next meeting for May 5
[15:20:57] <stpeter> and I will write up minutes from this meeting and the previous meeting, now that I'm caught up on email
[15:21:27] <waqas> MattJ: Yes
[15:21:47] waqas leaves the room: Replaced by new connection
[15:21:53] waqas joins the room
[15:23:03] <stpeter> ok, so I think we're done
[15:24:24] <stpeter> thank you all, and sorry about the lack of an agenda -- that will be fixed next time
[15:25:16] <stpeter> I'm in a conference call so I'm going to mostly ignore this room for a while
[15:25:54] <dwd> stpeter, I thought it went very well despite of - or perhaps because of - the lack of planning.
[15:26:19] <MattJ> waqas, was just wondering if you had anything on your mind to add
[15:26:22] <dwd> despite of? WHat kind of language is that. "In spite of", or "Despite", of course.
[15:27:04] <stpeter> you'll note that at the XMPP Summit I never have a defined agenda -- I prefer to define it at the conference (Just In Time)
[15:27:28] <MattJ> Yes, I like the stpeter-style JIT agendas :)
[15:27:29] <waqas> MattJ: On S2S, sure. But the discussion was nearing the end when I looked.
[15:27:49] <dwd> Right, time to go shoot things.
[15:27:58] <MattJ> waqas, on anything. I'm sure we can gather our s2s thoughts by 5th May :)
[15:29:28] <waqas> The main thing I was thinking of was collapsing the two connections into one after dialback was completed. May 5th is a long way away. :)
[15:30:05] <stpeter> waqas: we could do it sooner
[15:31:25] <waqas> Whenever everyone has time :)
[15:31:34] <stpeter> doesn't Prosody have a release on the first of every month?
[15:32:12] <waqas> May 1st, Labor day. Maybe :)
[15:32:16] <stpeter> April 28?
[15:32:41] bct leaves the room
[15:34:00] <Tobias> stpeter: prosody releases are related to number of threads launched at matt ;)
[15:34:08] <stpeter> Tobias: :)
[15:34:20] <stpeter> I thought there was a monthly release
[15:35:35] <Tobias> stpeter: well...we have some rough release cycle
[15:35:52] <Tobias> i'd prefer it more timed and on the clock
[15:36:23] vArDo joins the room
[15:37:34] <waqas> Avergae time between Prosody releases has been around 1 month. Though the latest release was delayed by about a month.
[15:37:42] <waqas> *Average
[15:37:44] <Tobias> maybe it's a german thing to want it to be more scheduled and consistent
[15:37:45] <Tobias> ;)
[15:37:59] <waqas> Tobias: It's a german thing.
[15:39:22] <Tobias> waqas: at least that want the movies tell you ;) the hollywood movies...but in those the germans eat sauerkraut all the time ;)
[15:41:54] <stpeter> Tobias: you are part of the Prosody Cabal, too?
[15:42:16] <Tobias> Cabal?
[15:42:25] <stpeter> team :)
[15:42:28] <Tobias> ahh
[15:42:29] <Tobias> yeah
[15:42:47] <waqas> Tobias: You don't eat sauerkraut all the time? ^^
[15:42:48] <stpeter> cabal = "a secret political clique or faction"
[15:43:04] <Tobias> cabal means team for you...my dict just shows more unfriendly terms :D
[15:43:20] <Tobias> stpeter: thanks for the explanation ;)
[15:44:00] <Tobias> stpeter: yeah...i'm the one to blame that people can log into prosody via SASL ;)
[15:44:56] <Tobias> waqas: i rarely eat sauerkraut...it's not my favorite food...but i eat it if i have no other option :D
[15:45:18] Sonny joins the room
[15:47:29] Sonny leaves the room
[15:49:51] Xificurk leaves the room
[15:50:52] Xificurk joins the room
[15:52:16] Flo joins the room
[15:55:18] nolan joins the room
[16:03:39] jeti leaves the room
[16:04:00] vArDo leaves the room
[16:05:58] remko leaves the room: Logged out
[16:10:28] dirk leaves the room
[16:12:33] piers leaves the room
[16:24:09] Flo leaves the room
[16:24:45] Grom joins the room
[16:28:03] huni leaves the room
[16:33:06] jack leaves the room
[16:33:10] jack joins the room
[16:34:38] <Tobias> stpeter: is IETF's XMPP WG ml mostly dead? :)
[16:37:18] <stpeter> Tobias: so far, yes
[16:37:35] <stpeter> Tobias: we're waiting to see if the WG is approved
[16:37:42] <Tobias> stpeter: okay...just wanted to check that i didn't break anything :)
[16:37:49] <Tobias> WG to be approved
[16:37:51] <stpeter> nope
[16:37:59] <stpeter> nothing broken :)
[16:38:11] <Tobias> i guess IETF workings are far to complex to get involved there :D
[16:38:24] <stpeter> yes :)
[16:38:47] <stpeter> you think the XSF has too much process? just get involved with the IETF :)
[16:38:57] <stpeter> now, they are a lot bigger
[16:39:01] <stpeter> so I understand the need
[16:39:29] <Tobias> so something needs to be approved until the open community can discuss it?
[16:39:32] <Tobias> sounds weird
[16:39:39] <stpeter> well
[16:40:00] <stpeter> there's no need to talk on xmppwg@xmpp.org until we need to -- until then we'll just keep talking on standards@xmpp.org
[16:40:48] <Tobias> yeah
[16:43:44] darco joins the room
[16:44:06] darkrain42 leaves the room
[16:44:14] darkrain42 joins the room
[16:44:31] Astro leaves the room
[16:44:35] nolan leaves the room
[16:48:22] <Tobias> well..gn8
[16:49:03] Florian leaves the room
[16:49:40] stpeter writes up some minutes about today's discussion
[16:51:44] stpeter has set the subject to: Jabber/XMPP Development | Logs: http://logs.jabber.org/jdev@conference.jabber.org/
[16:57:32] jack leaves the room: Replaced by new connection
[16:57:37] jack joins the room
[16:59:38] stark joins the room
[17:01:08] <stark> holaaaaa a todos
[17:01:12] <stpeter> hi
[17:02:00] Dan Siemon joins the room
[17:02:05] bct joins the room
[17:02:06] <stark> hola alguien me lee
[17:02:12] <stpeter> !es
[17:02:13] <xepbot> Puedes hablar en espaƱol en jabberes@conf.jabberes.org y consultar tus dudas sobre Jabber
[17:04:04] bct leaves the room
[17:04:35] stark leaves the room
[17:04:37] <darco> I wonder how these people find their way into jdev.
[17:05:09] Tobias leaves the room
[17:05:33] jack leaves the room: Replaced by new connection
[17:05:37] jack joins the room
[17:07:02] jack leaves the room: Replaced by new connection
[17:10:02] <stpeter> minutes sent
[17:10:19] <stpeter> darco: the ways of the Internet are mysterious indeed :)
[17:28:21] waqas leaves the room: Replaced by new connection
[17:36:03] waqas joins the room
[17:38:33] <stpeter> also posted the minutes here with a few changes http://blog.xmpp.org/?p=373
[17:38:45] <stpeter> one if by list, two if by blog :)
[17:39:25] msvox joins the room
[17:40:22] msvox leaves the room
[17:56:42] steve-e leaves the room: offline
[17:57:37] <darco> It is really too bad that TCP implementations don't provide enough information on how much of the output buffer has been ack'd by the opposite side. Because, theoretically, the Ack part of http://xmpp.org/extensions/xep-0198.html [http://xmpp.org/extensions/xep-0198.html] is somewhat redundant. They say TCP is a reliable transport, but is really isn't 100% reliable in all cases, and XMPP happens to be one of the cases where this unreliability can really hurt.
[17:59:05] <darco> but then again, I haven't looked very carefully. For all I know, most OSs could already have a way to get this information. (Thru an ioctl call, perhaps)
[17:59:55] <MattJ> Yes, TCP is bad
[18:00:14] <darco> It's a nightmare for mobile implementations
[18:00:33] <darco> This is one area where BOSH is much better than the plain vanilla XMPP stream
[18:01:39] stpeter points MattJ to #jabber
[18:01:59] <MattJ> darco, that's only because it's another layer of [indirection] :)
[18:01:59] <xepbot> Any problem in computer science can be solved with another layer of indirection
[18:02:25] <darco> Well, yes
[18:03:06] <MattJ> !but
[18:03:06] <xepbot> ...but that usually will create another problem.
[18:03:24] <MattJ> There is the obvious problem of overhead
[18:03:25] <stpeter> heh
[18:04:19] <stpeter> ok, time to catch the train, bbl perhaps :)
[18:04:38] <MattJ> See you :)
[18:04:51] Xificurk leaves the room
[18:04:55] stpeter leaves the room: Logged out
[18:05:17] Christian leaves the room
[18:05:34] Xificurk joins the room
[18:06:20] <darco> It's not so much that TCP is bad, it's that most implementations either don't give you enough information about what has been ack'd, or don't have an obvious way to do so.
[18:06:53] <darco> Another way around this would be to move to a UDP based protocol. But that has it's own issues (large stanzas, etc),
[18:08:34] <darco> brb
[18:08:59] Christian joins the room
[18:10:25] johnny joins the room
[18:10:56] <MattJ> Yeah
[18:12:22] darco leaves the room
[18:29:43] bct joins the room
[18:43:45] darco joins the room
[18:48:41] hawke leaves the room
[18:50:05] johnny leaves the room
[18:50:35] waqas leaves the room: Replaced by new connection
[18:51:27] darkrain42 leaves the room
[18:51:45] darkrain42 joins the room
[18:53:25] johnny joins the room
[19:01:39] jkhii leaves the room: Logged out
[19:20:40] Yota_VGA leaves the room: Replaced by new connection
[19:20:44] Yota_VGA joins the room
[19:29:49] jkhii joins the room
[19:33:44] Christian leaves the room
[20:04:45] sezuan joins the room
[20:06:22] sezuan leaves the room
[20:07:47] darco leaves the room
[20:08:27] Yota_VGA leaves the room
[20:16:28] dragonlelo leaves the room
[20:26:46] Dan Siemon leaves the room: offline
[20:37:00] pavlix leaves the room
[20:39:54] darkrain42 leaves the room
[20:39:59] darkrain42 joins the room
[20:42:56] MattJ leaves the room
[21:07:43] brooklynmoon joins the room
[21:35:32] Lega joins the room
[21:38:57] Lega leaves the room: Replaced by new connection
[21:39:01] Lega joins the room
[21:41:46] <brooklynmoon> Anybody in brooklyn
[21:42:49] brooklynmoon leaves the room
[21:51:40] js leaves the room
[22:32:35] jack joins the room
[22:37:01] bct leaves the room
[22:44:52] lechu joins the room
[22:46:19] lechu leaves the room
[23:05:21] jkhii leaves the room: Logged out
[23:26:32] Flo joins the room
[23:40:44] darkrain42 leaves the room
[23:41:44] nabatt leaves the room
Powered by ejabberd Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!