XSF Discussion - 2014-03-26


  1. Simon has left

  2. Alex has left

  3. intosi has left

  4. intosi has joined

  5. martin.hewitt@surevine.com has joined

  6. martin.hewitt@surevine.com has left

  7. tato has joined

  8. Lance has joined

  9. tato has left

  10. Lance has joined

  11. martin.hewitt@surevine.com has joined

  12. emcho has left

  13. emcho has joined

  14. martin.hewitt@surevine.com has left

  15. emcho has left

  16. emcho has joined

  17. martin.hewitt@surevine.com has joined

  18. martin.hewitt@surevine.com has left

  19. martin.hewitt@surevine.com has joined

  20. martin.hewitt@surevine.com has left

  21. martin.hewitt@surevine.com has joined

  22. Lance has joined

  23. martin.hewitt@surevine.com has left

  24. Lance has joined

  25. martin.hewitt@surevine.com has joined

  26. emcho has left

  27. emcho has joined

  28. martin.hewitt@surevine.com has left

  29. martin.hewitt@surevine.com has joined

  30. Lance has joined

  31. emcho has left

  32. emcho has joined

  33. Lance has joined

  34. martin.hewitt@surevine.com has left

  35. Lance has joined

  36. martin.hewitt@surevine.com has joined

  37. martin.hewitt@surevine.com has left

  38. Simon has joined

  39. Kev has left

  40. Lance has joined

  41. martin.hewitt@surevine.com has joined

  42. jabberjocke has joined

  43. emcho has left

  44. emcho has joined

  45. martin.hewitt@surevine.com has left

  46. martin.hewitt@surevine.com has joined

  47. Tobias has joined

  48. jabberjocke has left

  49. Lloyd has joined

  50. Ash has joined

  51. Ash has left

  52. Ash has joined

  53. Lloyd has left

  54. Lloyd has joined

  55. Kev has joined

  56. Lance has joined

  57. Zash has joined

  58. Lance has joined

  59. edhelas has joined

  60. edhelas has left

  61. edhelas has joined

  62. edhelas has left

  63. Simon has left

  64. simon@imaginator.com has joined

  65. Lance has joined

  66. Lance has joined

  67. emcho has left

  68. emcho has joined

  69. Alex has joined

  70. Steffen Larsen has joined

  71. Kev has left

  72. mathieui has left

  73. mathieui has joined

  74. simon@imaginator.com

    @xmpp is now ready for the XSF marketing team.

  75. simon@imaginator.com

    (when it's formed up and ready to go)

  76. Santiago26 has joined

  77. Steffen Larsen has joined

  78. Ash has left

  79. Ash has joined

  80. Maranda has joined

  81. jabberjocke has joined

  82. Santiago26 has left

  83. Ash has joined

  84. Neustradamus has joined

  85. Alex has joined

  86. jabberjocke has joined

  87. Maranda has joined

  88. Zash has left

  89. Kev

    Protocol question for folks.

  90. Kev

    I'm writing up a spec for standardising 'form publishing'. This is where you publish a bunch of form templates to pubsub, and other entities can fill them in and publish the result to a node that will then be derived from the node the template is in.

  91. Kev

    I think we have no mechanism for standardising pubsub node names, am I right?

  92. MattJ

    I think you are right

  93. simon@imaginator.com

    nothing that I'm aware of. We went as as far as doing a "well known nodes" for Buddycloud.

  94. Kev

    That is, I'm considering that you could do something like say "Any node of the form urn:xmpp:form:templates:X" is a form of type X, which is published to a node urn:xmpp:form:completed:X.

  95. Kev

    What you want to do is to mix up the standardisedness (i.e. This is most certainly a form template) with the unstandardisedness (i.e. This is a form template for Bob's Quiz".

  96. Kev

    What are people's thoughts on this?

  97. simon@imaginator.com

    are you trying to define a content type with these forms?

  98. Kev

    (I have a real requirement around this, including multiple vendors interoperating)

  99. Kev

    simon@imaginator.com: The form is just a xep4 form.

  100. Kev

    The idea is that a deployment can choose to have whatever templates it chooses.

  101. MattJ

    Seems a bit hacky (potentially dangerous) to me, if I understand you right

  102. Kev

    MattJ: What's the Right Way of doing it?

  103. MattJ

    That I don't know :)

  104. MattJ

    But you're saying the forms should be discoverable based on just knowing the pubsub service they are hosted on?

  105. Kev

    Recursively, through disco, yes.

  106. Kev

    e.g. you disco your home server, find a pubsub service, find the templates on it, and are from that able to work out the corresponding 'completed forms' nodes as well.

  107. MattJ

    It seems ok, but it's quite conceivable that some services treat node names as opaque strings which are user-controlled

  108. Kev

    What do you mean by that?

  109. Kev

    The service isn't mandating the node names here, it's a convention to allow discovery.

  110. dwd has joined

  111. Kev

    The best I currently have is that we do urn:xmpp...template#THEIR_FORM_URI.

  112. Kev

    As the node names for each template form.

  113. Kev

    And urn:xmpp...completed#THEIR_FORM_URI for the corresponding completed forms.

  114. Kev

    Which, as far as I can immediately see, works but isn't elegant.

  115. MattJ

    I understand what you want, I think I need to think about it more

  116. Kev

    I can go ahead and write up the XEP proposal on this basis.

  117. Kev

    Indeed I'm tempted to, as it seems to meet our Experimental criterion (nott immediately obvious that it's wrong).

  118. Kev

    But I'd be happier if it was immediately obvious that it's right :)

  119. dwd

    Kev, I think what you're proposing works, but you might want a form template to provide where it should be posted to.

  120. Kev

    dwd: Why might you want that?

  121. dwd

    Kev, that is, a form template node would contain a wrapper element containing metadata including a form destination.

  122. Kev

    i.e. My use case doesn't require more flexibility than I propose (and you know what my use case is).

  123. dwd

    Kev, Why would you want to prevent that flexibility?

  124. Kev

    Layers of abstraction are only good when they're useful?

  125. dwd

    Yeah, but you're largely making this a dead-end in terms of extensibility, aren't you?

  126. MattJ

    Kev, FWIW I agree with solving this in some way... I know someone who has a similar need and would love a standard protocol for it

  127. Kev

    dwd: I don't see why.

  128. Kev

    That is, I can't see what extensibility is prohibited by this.

  129. Kev

    But I can see that it's considerably more complex.

  130. Link Mauve

    What is the use-case, btw?

  131. Kev

    Link Mauve: Someone wants the admins to be able to publish a set of form templates, and for users to be able to fill them in and submit them.

  132. Kev

    When they have a need to make sure a report.

  133. Link Mauve

    Ok.

  134. Alex has joined

  135. Kev

    So you have a "Kev turns up for work late" template, and when Edwin notices that I get into work late, he'll find the relevant template in the list his client has found, fill it in, and hit submit. Then someone else is watching the node to take some action.

  136. dwd

    Kev, It's just a small wrapper element. You can default the target node if you want.

  137. simon@imaginator.com

    Isn't that call Lotus Notes?

  138. Kev

    dwd: It adds an amount of non-obvious complexity.

  139. Kev

    dwd: Now in order to watch for new publishes, an entity needs to first fetch all the templates, to dereference the publish target.

  140. Kev

    dwd: Then when a new version of a form is published (new item to the template node), you have issues with how to handle the semantics of changing the destination (I assume this is not allowed).

  141. Link Mauve

    Why don’t you use node metadata for the suggested post node?

  142. Kev

    So while it's certainly more flexible, I'd like someone to come up with a reason that it's a requirement somewhere before we go making it less suitable for my requirements.

  143. Kev

    Link Mauve: In what way?

  144. Link Mauve

    <field var='x-pubsubform#post_node' label='POST Node' type='jid-single'><value>forms@pubsub.kev.tld/kev_turns_up_for_work_late</value></field>

  145. Link Mauve

    For example.

  146. Link Mauve

    Or maybe jid-multi.

  147. Zash has joined

  148. Kev

    Link Mauve: Doesn't that then prevent us using a standard pubsub service for this?

  149. Link Mauve

    Standard PubSub services disallow custom metadata?

  150. dwd

    I don't think it's part of the spec, no.

  151. dwd

    Which is not to say it shouldn't be.

  152. Kev

    AFAIK, there is no standard method of configuring node metadata.

  153. dwd

    We should probably fix that. Buddycloud will/does need it I think.

  154. dwd

    Kev, By the way, anyway of sending custom XML stuffs in Swift?

  155. Kev

    No. Should be trivial to add to the Debug Console. Do you need it?

  156. dwd

    (Or indeed on anything short of telnet on a Mac)

  157. Kev

    Sluift.

  158. Kev

    Or, for that matter, Psi.

  159. dwd

    Kev, Only as an immediate debuggery aid. I've an Openfire server acting potentially odd, need to isolate the client.

  160. dwd

    Oh, Psi.

  161. Laura has joined

  162. dwd

    Laura: Hello Colleague!

  163. Kev

    fippo / Tobias: Do you have thoughts on the above?

  164. MattJ

    potentially

  165. Tobias

    Kev, well..i think the reply target of a form should be in the form, but as you said, this makes it quite unconvienient to subscribe to them. You want an out of form discoverable way, which says "forms that match this pattern (i.e. of type X or have name 'late') or so go to pubsub node foo

  166. stpeter has joined

  167. Kev

    Tobias: Can you see a way in which having a simple transform for template->submission node wouldn't work?

  168. Tobias

    template being what? just an empty form?

  169. Kev

    Yes.

  170. Laura

    Dave: waves

  171. Tobias

    Kev, how about when forms are supposed to go to different nodes based on the person who requested it?

  172. Kev

    Do you have such a requirement?

  173. Lance has joined

  174. Tobias

    nope...but it doesn't fell far fetched...sure one could say those different people just have to fetch different forms then

  175. Kev

    That one would be very difficult to solve. You want to provide a different publishing target to every person who requests one.

  176. Kev

    So you can't embed it in the form, you can't embed it in metadata.

  177. Tobias

    not to everyone but maybe per group...well the service could embed it in the form the moment the user requests the template

  178. Tobias

    but that's way off standard pubsub i think :)

  179. Kev

    Somewhat.

  180. Tobias

    Kev, so i'd be +1 on you writing a XEP and see what precisely you propose

  181. Kev

    Does that mean you're not anticipating -1ing it?

  182. Kev

    My motivation to XEPpify it if the idea's so bad it can't go to Experimental is limited :)

  183. Tobias

    hehe :)

  184. Tobias

    so basically you disco some well known node and ask where forms of template X are supposed to be posted to?

  185. Kev

    No.

  186. Tobias

    then i've misunderstood you

  187. Kev

    You disco the pubsub service. It tells you what nodes are there.

  188. Kev

    Nodes with a well-defined prefix are templates. You query them to get the templates.

  189. Kev

    To get the publishing form you take the node and s/template/submission/ or something.

  190. bear has joined

  191. dwd

    Kev, ta for the tip to use Psi. I seem to have more or less duplicated an interesting bug in Openfire. Do we have any contacts for the developers?

  192. Kev

    Of Psi or Openfire?

  193. dwd

    Openfire.

  194. Tobias

    the openfire dev was in jdev from time to time

  195. Steffen Larsen has joined

  196. dwd

    Ah, cool. I'll try to remember to hang about there.

  197. Tobias

    or on twitter @guusdk

  198. SouL has joined

  199. bear

    Agenda for today (as it stands right now): UPnP Liason Team wiki Website update Hardware

  200. bear

    (probably also a twitter related update considering what I saw on twitter last night)

  201. SouL has left

  202. SouL has joined

  203. winfried has joined

  204. SouL has left

  205. simon@imaginator.com

    Bear - you are looking at last week's meeting trello :) I'd like to talk about our marketing (encompassing the website today).

  206. dwd has left

  207. bear sighs

  208. dwd has joined

  209. dwd kicks wifi.

  210. bear

    I am just happy that i'm awake after only 4 hrs of sleep

  211. Laura

    Simon: sorry I missed out website call! Opening up Trello boards now

  212. simon@imaginator.com

    Laura: don't worry - I've been working on the site generation in the mean time.

  213. Laura

    Hopefully you have seen from Trello - I have been busy on content!

  214. bear apologizes to simon for dropping that task

  215. simon@imaginator.com

    I have the Trello for Android App. My phone was ringing a lot!

  216. simon@imaginator.com

    Bear - don't worry - we can robustify later. This is more to get something displaying content and the warm happy feeling that will motivate editors.

  217. bear nods

  218. dwd

    I'm not entirely sure how much time I have, FYI. Certainly a half hour. But we've guests upstairs here, and I'm assuming I'll be dragged out for a beer against my will later.

  219. simon@imaginator.com

    I'm happy to keep it as short as possible too.

  220. simon@imaginator.com

    Nothing big from my side other than we now have @xmpp for our use (finally)

  221. Laura

    Dave is really struggling with all the beer in his first week with us

  222. simon@imaginator.com

    there - now nothing on my agenda.

  223. bear

    I also have nothing to talk about as I've been absent for a couple weeks

  224. dwd

    Laura, No, but the entire bottle of win in the hotel deal is a big of a strain.

  225. Kev

    A bottle of win.

  226. bear

    let's bang the gavel and open for AOB?

  227. simon@imaginator.com

    he's kicking wifi and drinking "win" — sounds like an interesting hotel.

  228. Laura

    Se, struggling

  229. dwd

    Kev, I'll blame the crappy keyboard. Some fruit related product.

  230. Kev

    Grapes, if I understand what you mean by 'win'.

  231. bear

    is ralphm present?

  232. bear

    dwd, laura, simon - shall we start?

  233. dwd

    Go for it.

  234. Laura

    Lets

  235. simon@imaginator.com

    shall we make this the quickest meeting ever?

  236. bear

    :)

  237. bear bangs the gavel

  238. dwd

    Over already?

  239. bear

    ok, dave, laura, simon and myself present - ralph abset

  240. bear

    Simon - XMPP on twitter update?

  241. bear

    other than "we have it and now can start using it"?

  242. bear

    anyone else have any AOB items?

  243. simon@imaginator.com

    Yes, Tim (lead architect on Sina Weibo (which uses XMPP internally and is writing us a whitepaper)) has transferred the @xmpp username to us.

  244. bear

    \o/

  245. stpeter

    simon@imaginator.com: great!

  246. bear

    nicely done sir on wrangling that!

  247. simon@imaginator.com

    Q: any good way to have a group of people using Twitter other than sharing a passwd?

  248. stpeter

    that deserves some recognition

  249. stpeter

    simon@imaginator.com: I am not aware of one, but that doesn't mean much

  250. bear

    shared password or us signing up for one of the enterprisy web apps

  251. dwd

    I suggest it's tied to an xmpp.org email address, and the password shared to sensible people (like PSA, Laura).

  252. bear

    I would also like to have it

  253. Laura

    We should limit the number of people sending the tweets too - mixed voices and messages confuse people

  254. simon@imaginator.com

    so that's my update. Website is keeping me busy but next week I should have more mental bandwidth to write up my XMPP "marketing team" proposal on how we can start getting more press.

  255. bear

    but yes, +1 to xmpp.org address and the short list of folks

  256. Laura

    Nice idea is to hand over the reins to a fifferent person each week, and indetify that on our feed

  257. dwd

    Laura, Right, I'd prefer one person primary with the rest of the password holders for emergency cover.

  258. Laura

    Encourages people to hear each voice

  259. Laura

    Imagine 5 people all tweeting at once - different styles etc. Messy.

  260. stpeter defers to Laura

  261. bear

    and that is why it's nice to have a marketing person in charge!

  262. stpeter

    you betcha!

  263. bear

    (in charge of "the message")

  264. Laura

    Happy to take that up

  265. bear

    ugh - my brain is mush

  266. Laura

    I could try for a week, and get feedback from you guys on the content, style etc next week?

  267. stpeter

    Laura: sounds awesome

  268. Laura

    See id you like it?

  269. Laura

    *if

  270. stpeter

    no typos allowed in our tweets :-)

  271. Laura

    I promise to be very careful

  272. dwd

    stpeter: Rite, that would be a dizzaster.

  273. Laura

    Now hand it over

  274. simon@imaginator.com

    Laura - I'll ping you after with the details.

  275. Laura

    Great

  276. bear

    :)

  277. stpeter

    "Now hand it over" :-)

  278. bear

    next item? AOB?

  279. dwd

    I sent out an invoice sample; heard back from Simon but nobody else.

  280. bear

    I will reply to that on the lists

  281. dwd

    I think after some thought that the EIN might be required, but it otherwise looks good on a re-review.

  282. dwd

    But otherwise I've nothing more. (Little snowed under with new job etc)

  283. stpeter

    dwd: I suppose the EIN isn't a bad idea

  284. simon@imaginator.com

    dwd: if you set the right juristriction in Wave - it makes sure to generate you a legal invoice.

  285. dwd

    stpeter: Yours had it, and some government agencies require it. May as well have it in for completeness.

  286. stpeter nods

  287. stpeter

    BTW I mentioned our athena woes to my UPnP Forum contact and he offered for them to buy us a new machine

  288. dwd

    Ah, OK. I've not followed up with my potential at all; I can do that as well.

  289. stpeter

    if we had a price estimate from the iteam I might be able to get something going quickly

  290. dwd

    My understanding from back around Christmas was that there were two machines that were getting quite tired.

  291. dwd

    Plus the iteam was, I thought, considering whether to maintain hardware or switch to a cloud provider.

  292. simon@imaginator.com

    Ralphm was also looking into getting a Rackspace box sponsored.

  293. simon@imaginator.com

    (could be easier than racking a new box)

  294. stpeter

    we moved to Rackspace temporarily

  295. bear

    having rackspace for the web content as backup is a great idea IMO

  296. Kev

    My preference would be to maintain the status quo. Jerry seemed a little put out that we'd moved athena away from him temporarily.

  297. stpeter

    the iteam needs to decide whether to make that permanent

  298. dwd

    Yes, but we get quite incredible service from USSHC; we need to think hard about whether we want to end that relationship.

  299. bear

    but some of what we run really should be run at the colo IMO

  300. stpeter

    Kev: Jerry cares about jabber.org - I suggest we move that back to apollo or somesuch

  301. stpeter

    and of course there's the question of xmpp.org and jabber.org, still :-)

  302. dwd

    FWIW, my gut feeling is to stick with Jerry. Invests in people instead of corporations, feels more satisfying. But I'll understand if the iteam want cloudish things as well (or even instead).

  303. Kev

    I'm not sure the iteam is pushing for a cloud at all.

  304. stpeter

    it's still on my list to figure out a more independent funding source for jabber.org (cooperative or something), which would enable jabber.org to have separate machines for various purposes

  305. Kev

    It seems to be the discussions in the Board meetings that keep coming back to cloudifying.

  306. dwd

    Kev, That's fine, too. :-)

  307. bear

    Kev - can we get an answer on price estimates from the iteam and then the cloud item will stop creeping into the conversation I think

  308. dwd

    Kev, I'm merely saying I'm not arguing the cloud option should be ruled out, not that I'm happy with it.

  309. dwd

    Could we have both hardware and price estimates. I may be able to get us a hardware sponsor, in which case the price is somewhat moot.

  310. bear

    +1

  311. Kev

    I'm writing a mail at the moment.

  312. bear

    thanks kev!

  313. Kev

    But I'm not a server hardware person.

  314. simon@imaginator.com

    I'm going to need to drop off in a minute. Anything else we need to go though after the hardware discussion?

  315. bear

    no, but some of the iteam folk are - and if they give specs some of us can translate that to hardware price estimates

  316. bear has nothing futhur for AOB

  317. dwd

    OK, I'm done with this.

  318. stpeter

    dwd: +1 that would be helpful for the offer from UPnP Forum, too

  319. dwd

    (And no further AOB)

  320. stpeter

    nothing further here

  321. Kev

    bear: Yes, that's why I sent said email.

  322. bear

    meeting time same next week?

  323. Laura

    Great

  324. stpeter

    love these 30-minute meetings

  325. dwd

    Do we have an EU timeshift this weekend?

  326. Kev

    bear: Noting that the 'same time next week' is in fact 17:30 instead of 16:30Z.

  327. simon@imaginator.com

    yes

  328. Kev

    If you're doing it UK-time, as Council does :)

  329. bear

    yes, but since we use UTC the meeting time is the same

  330. dwd

    Assuming that Council has shifted, can we shift also?

  331. Tobias has left

  332. Kev

    bear: No, that's what I'm saying. You should shift the UTC time :)

  333. Laura

    That would be good for me, 5.30 could get trickier for longer meetings

  334. dwd

    I'd rather anchor to EU TZ shifting.

  335. stpeter

    I always set up the calendar entries to be UTC, if we need to change then let me know

  336. bear

    ah - the council time shifted

  337. Kev

    Or, at least, if your goal is to follow Council.

  338. Kev

    Council meets in UK time.

  339. bear

    yes, following council is easier on a lot of folks

  340. stpeter

    chronological imperialism!

  341. dwd

    Kev: Well, it follows EU timeshifting, at least. :-)

  342. bear

    +1 to shifting out time - anyone object?

  343. Kev

    dwd: In the last discussion we had on the topic (and previous) Council agreed to meet at a given UK time :)

  344. simon@imaginator.com has left

  345. bear

    not hearing of any objections... ok, we shall shift our time also

  346. stpeter

    Kev, so Council will move from 16:00 to 17:00 and Board will move from 16:30 to 17:30, right?

  347. Kev

    stpeter: Correct.

  348. stpeter

    noted!

  349. Kev

    In Zulu time :)

  350. Laura

    So 5.30pm UK time?

  351. dwd

    Laura, No, it's unchanged in UK.

  352. bear

    Laura - yes

  353. Kev

    Wait. No. I've screwed this up.

  354. Kev

    It's -1, not +1

  355. dwd

    (Or it should be)

  356. Kev

    So 15:00 and 15:30.

  357. bear shuts up about someone else's time zone

  358. Kev

    To counter the +1

  359. stpeter

    yes

  360. Kev

    So it remains 16:00 and 16:30 UK.

  361. dwd

    How many XMPP experts does it take to schedule a meeting?

  362. Laura

    Kev: great

  363. stpeter

    heehee

  364. bear

    i've seen CalDAV experts mess up TZ calculations before...

  365. bear

    thanks all - I think simon banged the gavel as he was leaving

  366. stpeter

    ok!

  367. Laura

    Bye folks

  368. bear waves and wanders off to find where his brain is having breakfast

  369. Steffen Larsen has joined

  370. dwd has left

  371. SouL has joined

  372. SouL has left

  373. SouL has joined

  374. bear

    something on one of my computers is beeping at me

  375. Kev

    bear: Is that because I keep saying your name in council@?

  376. bear

    nope - it's silly facebook

  377. bear

    I forgot that I had the tab running and everytime it updates the timeline it beeps

  378. Lloyd has left

  379. Neustradamus has joined

  380. SouL has left

  381. martin.hewitt@surevine.com has left

  382. Ash has joined

  383. Ash has left

  384. emcho has left

  385. Steffen Larsen has joined

  386. emcho has joined

  387. Laura has left

  388. martin.hewitt@surevine.com has joined

  389. Lance has joined

  390. Steffen Larsen has left

  391. Steffen Larsen has joined

  392. Steffen Larsen has left

  393. emcho has left

  394. emcho has joined

  395. martin.hewitt@surevine.com has left

  396. emcho has left

  397. martin.hewitt@surevine.com has joined

  398. emcho has joined

  399. martin.hewitt@surevine.com has left

  400. Lance has joined

  401. bear has left

  402. Santiago26 has joined

  403. martin.hewitt@surevine.com has joined

  404. Maranda has joined

  405. Maranda has left

  406. Maranda has joined

  407. martin.hewitt@surevine.com has left

  408. Santiago26 has left

  409. Maranda has left

  410. Maranda has joined

  411. martin.hewitt@surevine.com has joined

  412. Lance has joined

  413. Lance has joined

  414. martin.hewitt@surevine.com has left

  415. Tobias has joined

  416. Tobias

    emcho, there?

  417. Maranda has left

  418. martin.hewitt@surevine.com has joined

  419. Tobias has left

  420. Tobias has joined

  421. simon@imaginator.com has joined

  422. martin.hewitt@surevine.com has left

  423. Tobias has left

  424. martin.hewitt@surevine.com has joined

  425. stpeter has left

  426. martin.hewitt@surevine.com has left

  427. winfried has left

  428. martin.hewitt@surevine.com has joined

  429. martin.hewitt@surevine.com has left

  430. martin.hewitt@surevine.com has joined

  431. Alex has left