[haiku-development] Re: /apps and /preferences and the common folder
- From: Stephan Assmus <superstippi@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Fri, 24 Oct 2008 21:09:42 +0200
Rene Gollent wrote:
> On Fri, Oct 24, 2008 at 1:24 PM, Humdinger <humdingerb@xxxxxxxxxxxxxx>
> wrote:
> > Hi there!
> > Suppose I have a custom 3rd party input_server. The Haiku original is
> > in /boot/beos/system/servers/input_server. Will my custom input_server
> > override the original when I put it in either /boot/common/servers/ or
> > /boot/home/config/servers/? I.E., I can just create the non-existing
> > "servers" folder and it works?
>
>
> Generally speaking, most of the extra stuff you can install in
> /boot/home/config or /boot/common is meant to supplement, not replace.
> There isn't really a mechanism in place generally to say "if this or that
> gets loaded from ~/config, don't load its analogue in /system".
> ~/config/servers for instance has been used in the past on BeOS to add
> extra servers such as the im_server that IM Kit uses. In any case
> replacing any of the critical system servers entirely would be a
> decidedly non-trivial undertaking, and it's pretty unlikely a third party
> would attempt this, especially as most of them are extensible via add-ons
> in some way or other.
Since Haiku is open source, no one should bother to reimplement one of the
servers or system apps like Tracker or Deskbar. Instead, they should just
work on and improve the originals.
That being said, the intention is that stuff in common or home/config can
override system stuff. With the new driver architecture for example, only
one driver could control a device (not so with BeOS style drivers), and
home/config is scanned before common/ which in turn is scanned before
system/. I believe BeOS/ZETA do look out for drivers that have the same
name and then prefer the user provided one. Not sure about Haiku here.
As for servers and Tracker/Deskbar... these are launched in the Bootscript
and it would be trivial to check common or home/config for user provided
replacements in the script. But there may be problems in the details, like
the already mentioned application signatures. A lot of these apps work
together and know each other by signature and have some messaging protocols
which the follow and expect from each other. This is a form of "loose
binding" but it's easy to break stuff anyways if you don't know what you're
doing.
To sum up, for drivers, it is certainly intended to have user provided
drivers override system drivers. But even there, it makes more sense to
just fix the original component. For servers, it's not really anticipated.
If different behaviour is wanted, it's certainly possible to replace stuff
and to adopt the system for these situations where it currently hardcodes
stuff.
But it's always best to wait for an actual situation with a need, than to
try and anticipate them and pour work into something which no-one needed in
the end.
Best regards,
-Stephan
Other related posts:
