Replying to this would have been much easier if you'd not top posted! On Mon, Apr 1, 2013 at 1:06 PM, Peter Waher <[email protected]> wrote: >> The iqs are bare JID instead of full JID. > Yes. Many sensor configurations may be done in a production environment, > where runtime resource/session information is not available. This simplifies > things. It's not a limitation though.
It's quite a limitation - I don't think iq routing to bare JIDs works the way you think it does :) (No client will receive these requests) >> Why not use type='error' for error stanzas? > > Because an "error" on the sensor level is not necessarily an error at the > transport level. A sensor reporting an error, might be an OK > response/message. To be able to answer more precisely, could you provide an > example, or link to an example in the document which you think should be done > in another way? An iq type of error doesn't mean an iq wasn't delivered - it means that the receiving entity couldn't successfully process the request. For example: <iq from='[email protected]' to='[email protected]' type='result' id='3'> <rejected xmlns='urn:xmpp:sn' seqnr='3'/> </iq> The type=result here roughly means "yep, did what you asked" and type=error would roughly mean "I can't or won't do what you asked". >> Why not send iq responses after processing, instead of before? > I'm not sure I follow you. Could you provide more info on what is the > concern, or point to an example which illustrates the concern? Not a concern, per se, I'm just wondering if it makes more sense to do: iq get (sent me some data) messages messages messages (here're the data you asked for) iq result (all done!) instead of iq get (sent me some data) iq result (all done!) messages messages messages (here're the data you asked for) >> Should times use 82? > ??? XEP-0082: XMPP Date and Time Profiles >> I'm not entirely sure that I understand the translation stuff. Isn't this >> equivalent to using strings in e.g. English, and then having a translation >> map? > > That would be a subset of what the translation model can do, as a basic case: > Mapping string IDs to translated strings. This model also allows for modules, > sensors or devices to aggregate information to the field name, still making > it possible to make the end result localizable. Note that devices in the > sensor network will not be able to perform the localization themselves, so > the information has to be delivered to a system that can do it. I'll think further. This doesn't immediately seem unlike the normal translation model in applications where you provide a base translation, annotated internally, and that seems work work fine (and makes reading code/protocol much easier). > > Regarding EXI: >> I'm going to not object at the moment to it going to Experimental, although >> I do still have reservations about it. > Ok, which ones? The ones I enumerated previously - I'm happy to wait and see how this pans out once it's published. >> I'd quite like to know how EXI in this case compares to zlib (It looks >> rather like zlib should cope pretty well with these data). > EXI can compress XML several multiples better than zip, in the general case. > It is also very efficient execution wise. It of course all depends on type of > XML and availability of schemas. I'm sure numbers will be available later in > the process for explicit cases. Right, it's the numbers I'm interested in. /K
