XSF Discussion - 2013-01-27


  1. Lance has joined

  2. Lance has joined

  3. Lance has joined

  4. Lance has joined

  5. Lance has joined

  6. Jef has left

  7. Jef has joined

  8. Neustradamus has joined

  9. Jef has left

  10. Lance has joined

  11. Lance has joined

  12. Lance has joined

  13. Lance has joined

  14. Lance has joined

  15. Neustradamus has joined

  16. Lance has joined

  17. Lance has joined

  18. Lance has joined

  19. danial-l has joined

  20. danial-l

    Hi

  21. danial-l has left

  22. danial-l has left

  23. Jef has joined

  24. Neustradamus has left

  25. Neustradamus has joined

  26. Neustradamus has joined

  27. Jef has left

  28. Jef has joined

  29. Lance has joined

  30. Jef

    Hello Lance

  31. Lance

    hi Jef

  32. Jef

    i have question, can a muc relay and IQ query to all the occupants in the room?

  33. Lance

    it can, but how it does so, and how it handles the results isn't specified

  34. Jef

    how about instead of the room itself, maybe a service does it

  35. Lance

    ?

  36. Kev

    Or, to put it another way, no it doesn't :)

  37. Jef

    it can't be done?

  38. Kev

    Not with standard MUC.

  39. Lance

    if you implemented your own muc component, and decided how to deal with all of the responses, sure

  40. Jef

    Lance, by component you mean service?

  41. Jef

    which can be discovered by disco

  42. Lance

    right, I mean the service providing the muc rooms

  43. Jef

    hmmm...

  44. Jef

    thanks i will check it out

  45. Lance

    but you would most likely be better off just sending the queries to the room occupants instead

  46. Jef

    if i have one query and 100 occupants it would be troublesome

  47. Jef

    more so, i don't know which occupants can handle the query

  48. Kev

    Well, that, at least, you should know.

  49. Jef

    if they join the attached muc service, i could know that

  50. Jef

    so i just send the query to the service

  51. Kev

    They'll have caps in their presence.

  52. Jef

    oh

  53. Jef

    i haven't considered that

  54. Kev

    It would break the iq model if you started getting multiple responses to a single query.

  55. Jef

    ha.... i see

  56. Jef

    so that's an absolute no

  57. Lance has left

  58. Lance has joined

  59. Jef

    still, i find that sending a new IQ for each and every occupant is rather inefficient

  60. Lance

    sounds like you need might need mep

  61. Jef

    mep?

  62. Lance

    http://xmpp.org/extensions/inbox/mep.html

  63. Kev

    PEP for MUCs.

  64. Jef

    looks it it could solve the problem, yes... but it is a proto xep

  65. Jef

    i have no other choice then, but wait until it is ready

  66. Lance

    Jef: how much control do you have in this setup? Are these arbitrary clients joining the muc, or ones that you control?

  67. Lance

    because you could make your muc service do the initial query and then do a message broadcast with the results

  68. Jef

    no, they are arbitrary

  69. Jef

    Lance, it is for the FIS

  70. Lance

    ooh

  71. Lance

    I see

  72. Jef

    i want to send a search query

  73. Lance

    and search across all room occupants

  74. Jef

    yes

  75. Lance

    ok, then MEP wouldn't help in that case

  76. Jef

    :S

  77. Lance

    so, you'd need to do this like how MAM works

  78. Lance

    send the iq to the muc, muc queries occupants, muc forwards results via message wrappers to the requester, muc sends result iq

  79. Jef

    Message Archive Management?

  80. Lance

    yes

  81. Lance

    the pattern of send iq, receive series of result message stanzas, receive single result iq

  82. Kev

    I think I missed what you're trying to do.

  83. Jef

    Kev, it is about searching files

  84. Kev

    Ah.

  85. Jef

    Lance, then the muc would have to wait for every occupant to send the results?

  86. Kev

    It would, yes.

  87. Lance

    to send the final iq, yes

  88. Jef

    not optimal, but i guess that's the best we can do

  89. Jef

    maybe send a timeout with the query

  90. Lance

    hrm

  91. Lance

    we can't really solve the waiting issue without caching/versioning/etc, but we can make this look a bit nicer and not have all of these response stanzas

  92. Lance

    by declaring that a muc room's FIS root directory contains a directory for each occupant

  93. Lance

    and then the room proxies any requests for data in those directories to those occupants

  94. Jef

    and what about with you want to search all across with a single keyword

  95. Jef

    and what about when* you want to search all across with a single keyword

  96. Lance

    it would look exactly like doing it with another user. in this case the muc service knows how to mux all of the search results together into a single result

  97. Lance

    RSM goes out the window though :/

  98. Jef

    result set?

  99. Lance

    right, how do you reliably limit/page results from a search across multiple sources?

  100. Lance

    its doable if the muc caches the directory tree and metadata for its occupants

  101. Jef

    how about every result have an attribute with the jid of the occupant

  102. Jef

    i don't understand well how RSM becomes difficult

  103. Lance

    well, idk. i'd have to think some more. it may work just fine

  104. Ashley has joined

  105. Ashley has left

  106. Lance

    ok, chat based voting works with the new memberbot. It just needs to write output files like the old one

  107. Lance ponders how to integrate last message correction with voting