jdev - 2020-12-09

  1. Sam Whited

    Ah yah, fair enough so at least one thing uses it. I just don't understand why a table is something special or what the point of extracting the types out into that weird header bit is I guess

  2. Sam Whited

    The XEP doesn't really say what it's for. It gives search as an example and says "things might want multiple items" but I have no idea what that means.

  3. Sam Whited

    I am suprised to hear that Metronome uses 0055, I thought nothing used that one

  4. Sam Whited

    ah crap, and I was still misunderstanding how these item things works, each one has every field in the header. That makes sense, but I hvae no idea how to fit it in with the API for the rest of the API. Oh well, that's a question for tomorrow I guess

  5. lovetox

    Sam Whited, i would not "fit" it in with the rest of the API

  6. lovetox

    i think you should have 2 APIs

  7. lovetox

    one is a generic dataform API with which you should not be able to generate a reported form

  8. lovetox

    the second API is where you can *only* generate a reported form

  9. lovetox

    and on the other side, if a user receives a form, it should instantly evident for him if he uses the reported api to read it or the normal dataform api

  10. lovetox

    just dont try to fit this into one thing, its my opinion

  11. Kev

    Sam Whited: M-Link and Swift both support 55.

  12. Sam Whited

    lovetox: sort of, I don't mean I'm trying to cram it into the same API that handles normal forms, it will have to be a different thing, but it should at least fit in with the overall design of the package, if that makes sense, and I can't figure out a good way to handle items and making sure they all have all the required fields (I thought I had one, but I was wrong)

  13. Sam Whited

    Kev: thanks; sounds like I'll actually need to support this type of form then

  14. Zash

    API design is hard. Who knew?

  15. Sam Whited


  16. Kev

    55 is of limited use on open servers (e.g. jabber.org etc.), but very very useful on other types of deployment (which may or may not be on the Internet), e.g. a company server that lets you search for colleagues, or whatever.

  17. Zash

    Does anyone allow probing for presence, ignoring subscriptions in such a setting?

  18. Kev

    We don't, although it's a nice idea.

  19. Sam Whited

    I don't think we ever released it before HipChat went under, but we talked about that for a *long* time because presence caused one of our biggest performance problems

  20. Kev

    I don't follow on the link between those.

  21. Zash

    Scaling rosters is hard?

  22. Kev

    I don't think scaling the roster is hard per se, but the amount of (redundant) presence that is sent around is a significant amount of the runtime cost of the server. At least last I checked.

  23. Sam Whited

    Every person in the org was subscribed to every other person. If you had a large org you ended up getting thousands of presences every time you logged in. You only saw a handful of people at a time, but your connection was bottlenecked by presences for like 30 seconds just to log in. Not good.

  24. Kev

    And it completely blocks the stream on startup if you have too much.

  25. Kev

    Right, what Sam said.

  26. Sam Whited

    What Kev said :)

  27. Kev

    But I don't see the link between allowing probing without a subscription, and avoiding that.

  28. Kev

    At least, what I *understood* Zash to be asking was about being able to poll the presence of someone not on your roster, e.g. when you get them as a '55 result.

  29. Zash

    So you could limit subscriptions to your own team/department or something and <presence type=probe> on demand for some others.

  30. Zash


  31. Sam Whited

    Right, we wanted to not have a subscription and you'd just probe for the 10 people in your recent conversations or whatever and anyone in the room you were currently looking at. Maybe also subscribe as an optimization using some hand wavey criteria such as "also in the marketing department" or "we're probing for this person a lot, just do a subscription"

  32. Kev

    Ah. So it's not that it makes roster presence less costly, just that you could restrict roster size.

  33. Sam Whited

    Yah, I don't think we ever hashed out how exactly it would work but the general idea was "query for recent conversations, chat rooms that are currently open, and results in the @mention auto complete menu) or whatever

  34. Sam Whited

    (or in a 55 result, if we had used that)