Sam WhitedAh 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 WhitedThe 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 WhitedI am suprised to hear that Metronome uses 0055, I thought nothing used that one
test2has joined
sonnyhas left
sonnyhas joined
Sam Whitedah 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
lovetoxSam Whited, i would not "fit" it in with the rest of the API
lovetoxi think you should have 2 APIs
lovetoxone is a generic dataform API with which you should not be able to generate a reported form
lovetoxthe second API is where you can *only* generate a reported form
lovetoxand 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
lovetoxjust 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
KevSam 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 Whitedlovetox: 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 WhitedKev: thanks; sounds like I'll actually need to support this type of form then
ZashAPI design is hard. Who knew?
Sam WhitedIndeed.
Kev55 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.
ZashDoes anyone allow probing for presence, ignoring subscriptions in such a setting?
KevWe don't, although it's a nice idea.
Sam WhitedI 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
KevI don't follow on the link between those.
ZashScaling rosters is hard?
KevI 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 WhitedEvery 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.
KevAnd it completely blocks the stream on startup if you have too much.
KevRight, what Sam said.
Sam WhitedWhat Kev said :)
KevBut I don't see the link between allowing probing without a subscription, and avoiding that.
KevAt 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.
ZashSo you could limit subscriptions to your own team/department or something and <presence type=probe> on demand for some others.
ZashRight
gutuninghas joined
Sam WhitedRight, 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"
KevAh. So it's not that it makes roster presence less costly, just that you could restrict roster size.
Sam WhitedYah, 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
Sam Whited(or in a 55 result, if we had used that)