On 6 March 2010 14:09, Fabio Forno <[email protected]> wrote: > On Fri, Mar 5, 2010 at 5:30 PM, Peter Saint-Andre <[email protected]> wrote: > >> The point of SIFT is to be flexible and extensible, which means that a >> SIFT implementation inherently has more complexity. > > That's not necessary. I may implement only presence hush and expose it > using SIFT syntax. The implementation effort is quite simple: > - answer to disco queries with the correct features > - listen for incoming SIFT packets and just look for <presence/> elements > - reply with errors for all not supported filters > >> The SIFT command to >> hush presence is quite simple: >> >> <iq from='[email protected]/pda' >> id='uh2s64g9' >> to='[email protected]' >> type='set'> >> <sift xmlns='urn:xmpp:sift:1'> >> <presence/> >> </sift> >> </iq> >> >> The problem is that SIFT can also be used to hush messages and IQs, >> intercept or filter based on sender, etc. At a minimum, we'd need a >> better definition of error handling for any feature that a SIFTing >> server does not support. > > Uhm... error conditions are defined I see. Perhaps I just don't know > what to do when only some of the conditions in a SIFT stanza are > unsupported (I vote for doing nothing at all and send > <feature-not-implemented/>). > > Finally, I don't like too many ad hoc solutions and the proliferation > of namespaces for the same thing. I personally like SIFT since it > seems general enough for doing many things, and it already has support > for cleanly doing partial implementations. > > It is just not clear (for me at least) what really happens when iqs > are sifted, if it is possible for example to proxy disco#info or > #items requests, or what would happen for iq based deliveries if they > will be approved (though somebody already uses them). But I'm not > worried about this since this part of the spec could be better defined > in feature when SIFT will be really implemented > > Imho the only question at present is: are there server developers > interested in taking on SIFT? If not why? (the client part is trivial, > so I'm not worried about it) >
Implemented: http://prosody-modules.googlecode.com/hg/mod_sift/mod_sift.lua It's still a little rough around the edges, feedback welcome - but it should be suitable for developing clients against. More info at http://code.google.com/p/prosody-modules/wiki/mod_sift Hope this helps, Matthew
