On complexifigurability

[Tiago Vignatti]

Daniel,

On 04/05/2011 05:51 PM, ext Daniel Stone wrote:
> On Tue, Apr 05, 2011 at 04:30:38PM +0300, Tiago Vignatti wrote:
>>
>> But my point is (well, always was) to chop off the server internal
>> modules in parts so we can have a lean implementation for different
>> purposes and cover everyone's desires. The testing and conformance
>> could be stressed in a different way, but not just compiling and
>> forcing developers to use the thing.
>
> Sure, but at some stage there has to be a limit.  Every configuration
> option has a cost: in making the source files larger by putting #ifdefs
> everywhere - and you could argue we already have enough of those, by
> implementing the alternate codepath, by testing that both codepaths
> build, by testing that both codepaths work, by documenting it, by
> supporting users who use it, etc, etc.  The server is not exactly a
> simple place as is, so adding additional complexity should be carefully
> considered[0].
>
> So, if there's a demonstratable benefit, then cool! By all means.  But
> if we're doing it either just for the sake of it, or to provide an
> absolutely trivial savings in binary size which could be much better
> accomplished elsewhere[1], then I don't see that the tradeoff makes
> sense.  Even so, is the result really usable? No-one using relative
> devices wants no acceleration.

it's not about binary size, nor memory savings. They are not the main 
benefits we should be targeting when talking about the server 
modularization - or did you care about it as a motivation for xkbcommon?

It's about organization of the code really, which leads to correct 
driver API usage, so we could talk about deprecation and proper 
versioning of unused/old/unmaintained drivers - we would be enforcing 
ourselves to use correct interfaces. Privately. So, I'm sure if we pick 
90% of the code inside Xorg DDX we will see that they are used only for 
old drivers. IOW, why a newer server needs to support a very old driver?

        Tiago