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) bye -- Fabio Forno,
