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
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.
Sam Whited
I am suprised to hear that Metronome uses 0055, I thought nothing used that one
test2has joined
sonnyhas left
sonnyhas joined
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
gutuninghas joined
test2has left
gutuninghas left
alex-a-sotohas left
alex-a-sotohas joined
NosoyHacker404has left
NosoyHacker404has joined
sonnyhas left
sonnyhas joined
Yagizаhas joined
gutuninghas joined
sonnyhas left
sonnyhas joined
alacerhas left
gutuninghas left
alacerhas joined
alacerhas left
belonghas left
alacerhas joined
belonghas joined
sonnyhas left
sonnyhas joined
gutuninghas joined
Vaulorhas joined
gutuninghas left
lovetoxhas joined
lovetox
Sam Whited, i would not "fit" it in with the rest of the API
lovetox
i think you should have 2 APIs
lovetox
one is a generic dataform API with which you should not be able to generate a reported form
lovetox
the second API is where you can *only* generate a reported form
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
lovetox
just dont try to fit this into one thing, its my opinion
SouLhas joined
lovetoxhas left
machas joined
alacerhas left
tskhas left
tskhas joined
alacerhas joined
DebXWoodyhas joined
belonghas left
jubalhhas joined
moparisthebesthas left
Martinhas left
Martinhas joined
jubalhhas left
jubalhhas joined
jubalhhas left
jubalhhas joined
jubalhhas left
gutuninghas joined
jubalhhas joined
jubalhhas left
machas left
machas joined
gutuninghas left
jubalhhas joined
jubalhhas left
jubalhhas joined
jubalhhas left
kikuchiyohas left
kikuchiyohas joined
Guushas left
Kevhas left
jubalhhas joined
jubalhhas left
sonnyhas left
sonnyhas joined
goffihas joined
machas left
machas joined
jubalhhas joined
jubalhhas left
gutuninghas joined
Kevhas joined
Kev
Sam Whited: M-Link and Swift both support 55.
gutuninghas left
NosoyHacker404has left
belonghas joined
waqashas joined
edhelashas left
edhelashas joined
machas left
gutuninghas joined
gutuninghas left
jubalhhas joined
jubalhhas left
jubalhhas joined
waqashas left
gutuninghas joined
gutuninghas left
gutuninghas joined
gutuninghas left
belonghas left
belonghas joined
gutuninghas joined
lovetoxhas joined
gutuninghas left
lovetoxhas left
Neustradamushas joined
adityaborikarhas left
adityaborikarhas joined
gutuninghas joined
gutuninghas left
stpeterhas joined
debaclehas joined
lovetoxhas joined
stpeterhas left
xeckshas left
xeckshas joined
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)
Sam Whited
Kev: thanks; sounds like I'll actually need to support this type of form then
Zash
API design is hard. Who knew?
Sam Whited
Indeed.
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.
Zash
Does anyone allow probing for presence, ignoring subscriptions in such a setting?
Kev
We don't, although it's a nice idea.
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
Kev
I don't follow on the link between those.
Zash
Scaling rosters is hard?
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.
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.
Kev
And it completely blocks the stream on startup if you have too much.
Kev
Right, what Sam said.
Sam Whited
What Kev said :)
Kev
But I don't see the link between allowing probing without a subscription, and avoiding that.
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.
Zash
So you could limit subscriptions to your own team/department or something and <presence type=probe> on demand for some others.
Zash
Right
gutuninghas joined
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"
Kev
Ah. So it's not that it makes roster presence less costly, just that you could restrict roster size.
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