On Fr, 2011-06-24 at 16:31 +0200, Lukas Zeller wrote: > On Jun 24, 2011, at 9:08 , Patrick Ohly wrote: > > > The key question is: is the assumption that a peer supports extensions > > or is the assumption that it doesn't? > > So far, the assumption was that it does.
After some testing, my experience is the opposite. After adding some new X- chat extensions, all of the peers started to fail the "item copy" test because they didn't support these extensions. After reporting that, Memotoo added support. > > In the later case, they should not be marked unless the > > CtCap confirms it (which at the moment isn't possible) or the remote > > rule recognizes the peer and sets the field (possible with > > SETFIELDOPTIONS()). > > Or vice versa, these could be disabled for clients known to have > problems with extra properties. I'd say most clients can at least > handle unknown properties without crashing. Yes, but they don't store them. Either way, once it is configurable we can choose different defaults. > But setting "compare" and "merge" attributes is not so easy to > actually implement, because these are attributes in the field list, > which is considered immutable after config is read (one reason is in > multithreaded servers, which read the config once at startup time of > the daemon, and then allow session threads to read from one single > TConfigItem tree without need for locks). > So I'm not sure if it's worth the trouble for now. Probably not. > >> I guess just implicitly marking the "unprocessed" array field > >> available gives the same result, and also has the potential to at > >> least capture extra properties from other clients. > > > > Does it have to be marked as "available" to be used when parsing? > > Yes. I thought a lot about this, but IMHO it doesn't make sense to > accept data that won't be sent back later. Because when it is parsed > and appears in a client device, a user might change it and will > certainly be confused when it does not sync back to the originator. So > it's either parse and generate, or neither. With MAKE/PARSETEXTWITHPROFILE() the X-* property is parsed and generated. Probably because they don't really use CtCap information to determine which properties are available. Only the rules are checked. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ os-libsynthesis mailing list [email protected] http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
