jdev - 2020-12-09

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

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.

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

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

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

i think you should have 2 APIs

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

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

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

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

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

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)

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

API design is hard. Who knew?

Indeed.

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.

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

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

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

I don't follow on the link between those.

Scaling rosters is hard?

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.

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.

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

Right, what Sam said.

What Kev said :)

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

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.

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

Right

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"

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

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

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