XMPP Council - 2013-05-08


  1. Tobias

    anything important on the agenda for today?

  2. Kev

    The two proposals from yesterday.

  3. Tobias

    do we want to handle them this week or next? might be a bit close for today...

  4. Kev

    Today seems fine, we have two weeks to deal with them after the meeting.

  5. m&m

    mea culpa

  6. m&m

    I will not be able to attend today

  7. m&m

    even if I appear online!

  8. stpeter

    howdy

  9. Tobias

    hi

  10. stpeter

    brb

  11. Kev

    m&m: Ta.

  12. Kev

    Right, it is time.

  13. Kev

    1) Roll call.

  14. Kev

    I'm here.

  15. Tobias

    soami

  16. MattJ

    Me to

  17. MattJ

    o

  18. Kev

    I poked Ralph, and m&m's not here.

  19. stpeter

    "Harpier cries 'Tis time, 'tis time."

  20. Kev

    2)http://xmpp.org/extensions/inbox/pubsub-subs.html Accept?

  21. Kanchil

    Kev: http://xmpp.org/extensions/inbox/pubsub-subs.html: XEP-xxxx: Pubsub Subscription

  22. Kev

    I didn't really get the whole 'id' thing in this.

  23. MattJ

    I think it's so you don't end up with duplicates, for example

  24. Kev

    And I'm not sure that the security considerations should have been copy/pasted from user tune :)

  25. MattJ

    or can easily check for the presence of an item in the list

  26. MattJ

    The hash isn't correct, I checked :)

  27. MattJ

    It doesn't have a JID in it anyway

  28. Kev

    But, can't you easily check for the presence of an item in the list anyway?

  29. MattJ

    How?

  30. Zash

    http://xmpp.org/extensions/xep-0060.html#entity-subscriptions ← What about that format that already exists?

  31. Kanchil

    Zash: http://xmpp.org/extensions/xep-0060.html#entity-subscriptions: XEP-0060: Publish-Subscribe

  32. stpeter

    why not just use UUIDs?

  33. Kev

    Zash: It's a reasonable question - although I think the one-sub per item they're going for might be sensible.

  34. MattJ

    stpeter, well then you can let the server generate them for you... but that still lets you have duplicates of a subscription

  35. stpeter

    MattJ: ah, sure

  36. Kev

    MattJ: But won't you only have duplicates of a subscription if you put them there?

  37. Kev

    Or are you thinking of two clients with a race condition?

  38. MattJ

    With the hash, if I want to see if someone is subscribed to a node, I can just do a simple iq get for that item id

  39. MattJ

    Well two clients is a case it could easily happen

  40. stpeter

    given that we deferred most of the other "User *" specs for lack of interest years ago, I wonder what the compelling use cases are here...

  41. Kev

    stpeter: Presumably they have a use for it, and we don't judge community interest until going to Draft.

  42. Kev

    So I'm not opposing it.

  43. MattJ

    Me neither, it has some editorial work to be done, but I like it

  44. stpeter

    Kev: agreed, I was just curious

  45. Tobias

    i'm with MattJ here

  46. Kev

    3) http://xmpp.org/extensions/inbox/http-over-xmpp.html

  47. Kanchil

    Kev: http://xmpp.org/extensions/inbox/http-over-xmpp.html: XEP-xxxx: HTTP over XMPP transport

  48. Kev

    I need to read this.

  49. Kev

    I'm assuming the ultimate aim is to do XMPP over BOSH over HTTP over XMPP over websockets?

  50. stpeter

    heehee

  51. Tobias

    yeah..who wouldn't want that...

  52. MattJ

    Heh

  53. stpeter

    probably it's to tunnel HTTP over XMPP-over-EXI

  54. stpeter

    for some reason :-)

  55. MattJ

    It reminded me of this part of an interview with jer: http://prosody.im/pastebin/95529bb1-b125-46ff-ab0e-526f78b4f176

  56. Tobias

    wouldn't shoving it through IBB be way easier?

  57. Kev

    To be entirely fair, I /can/ see situations in which HTTP over XMPP might be a sensible thing to do.

  58. MattJ

    ...in 2001

  59. stpeter

    now, I admit it would have been helpful for our friends in Cuba a few years ago

  60. Kev

    So I need to vote onlist for this.

  61. Kev

    Matt /Tobias?

  62. MattJ

    I'm +1, but as ever it needs some work :)

  63. Tobias

    i'll vote on list too, after i've read it

  64. Kev

    OK.

  65. MattJ

    My thought on it is that people are going to do it anyway, and it's best to spec it

  66. Kev

    4) Date of next. I can't do next week. Week after?

  67. MattJ

    and this doesn't seem like a terrible solution

  68. MattJ

    Week after is fine

  69. Kev

    MattJ: I'm not opposed to the principle, but I've not read the spec at all, and I want to before voting.

  70. MattJ

    Yep, I understand :)

  71. Kev

    I'll take that as an OK from Tobias.

  72. Kev

    5) Any other business?

  73. Tobias

    yeah..fine with me as long as it ends up in the calendar

  74. stpeter

    as to AOB, the http-over-xmpp proposal raised the issue of whether we can re-use SHIM headers

  75. Kev

    I also haven't read that thread.

  76. stpeter

    heh ok

  77. MattJ

    I've read the thread, but not the SHIM spec

  78. stpeter

    our resident literalist took issue with my suggestion

  79. MattJ

    :)

  80. stpeter

    Kev: no worries, we can discuss on the list

  81. stpeter

    maybe XEP-0131 was worded too narrowly

  82. Kev

    I don't have anything intelligent to say here, at least.

  83. stpeter shrugs

  84. stpeter

    yep, understood :-)

  85. MattJ

    stpeter, you speak in the past tense, but it's still Draft :)

  86. Kev

    Although, at a very high level, I'm not sure re-use of 131 buys very much if people don't implement 131 much :)

  87. Kev

    But anyway, I'll try to catch up and comment on list.

  88. stpeter

    was, is, has been, will be...

  89. stpeter

    yep

  90. MattJ

    What will be will be

  91. Kev

    OK, we're done then?

  92. Tobias

    i think so

  93. MattJ nods

  94. Kev

    Right, thanks all.

  95. Kev bangs the gavel.

  96. Tobias

    thanks you

  97. MattJ

    Thanks

  98. stpeter

    Tobias: shall I update the calendar to remove next week's meeting?

  99. Tobias

    will it annoy people too much when it's wrong? :)

  100. stpeter

    maybe I'll add some June meetings while I'm at it

  101. Tobias

    i don't care personally

  102. stpeter

    fixing it now

  103. stpeter

    hmm, lots of php5-cgi processes using memory on athena, will have to check into that

  104. stpeter

    er, lots of CPU

  105. Tobias

    wordpress :)

  106. stpeter

    it's evil

  107. Zash

    moar caching!

  108. Tobias

    less dynamic pages

  109. stpeter

    calendar updated

  110. Kev

    Ta.