On Fri, Jan 21, 2011 at 02:53:30PM -0600, pl bossart wrote:
In addition to what Liam said...
Next, if everyone can add #defines and craft new strings to represent verbs, this central application/module will either ask for use cases that are not supported everywhere, or limit itself to 'common' use cases. Or do we expect to rewrite this on each and every platform?
Given the amount of OS integration involved and the way people do these things I'd imagine that the actual decision making module is probably going to be very OS specific - there's so much other infrastructure to hook into and so much variation in what that looks like that we will need to cope with random use cases being defined by the system. Making the values strings was largely a recognition of that, it means that people don't need to patch UCM if they want to go and do their own thing. This all makes it easier to adopt UCM and deploy new use cases.
Wouldn't it make sense to avoid branches and proliferation by limiting the definition of use cases and instead only allow for changes in configuration files?
I'm not 100% sure I'm parsing this correctly but if you're suggesting explicitly enumerating all use cases in the code I suspect you'd just see system integrators patching locally or abusing predefined use cases they don't currently need rather than working upstream to integrate their use cases. Distros and so on who need to work over a wide range of devices are more likely to be affected, I think the most effective thing for them is going to be to keep the standard repository of use case definitions actively maintained so that there's something for effort to coalesce around.