On 16.03.2015 23:06, Christian Schudt wrote: > Thanks Florian, generally I agree, but please read my answers below.
I was mostly having a modular XMPP client library in mind. Here, if you advertise support for 'carbons', the library code for forward will be loaded. And in Smack's case, it's the full 'forward' code, not only the part required for 'carbons'. But of course, one could split the 'forward' module further, i.e. smack-extension-forward-<whatIsRequiredForCarbons> and smack-extension-forward-<everythingElse>, but I don't see a appealing reason to put some effort into that. And if you feel like not advertising 'forward' but 'carbons', then I see no problem with that either. I guess there are no implementations that actually specify and build a dependency graph for XMPP extensions. So nothing should break. Same is true for the jingle file-transfer case. If you feel like treating a missing 'ibb' announcement as 'jingle filetransfer is disabled', then there is nothing preventing you from doing so. :) But IMHO that's not a good idea. - Florian
signature.asc
Description: OpenPGP digital signature
