Components?

[Maciej Katafiasz]

Hi,
as there was kinda heated up discussion on IRC today, I decided to have
myself flamed a bit and bring it up on list. Issue is - can (and more
importantly, should) D-BUS be used for components? I believe that answer
is "yes", or "almost yes, something similar could do".

First, what exactly is a component? It's basically a black box, that:
1) is loosely coupled with whatever code uses it. Loose coupling is the
key concept here - there is _no_ relationship between component and user
other than, well, being component and user. Nor there is a way to break
that rule
2) is cleanly separated from outside - related to 1), means that there
never is any dependency between user and component, and all interaction
is explicit. All users are indifferent to components, and all components
(of given type) are indifferent to users. Also, component can never
change its behavior based on something outside of scope of component /
user relation, unless it is given in contract (which brings it again
into scope)
3) exposes interface - component gives a contract, which states how is
it going to interact with user. Interface is a way to actually use
component, other than that, it's black box.
4) has complete interface - every aspect of component that is somehow
sigificant to outside is included into public interface. Again,
everything goes within contract
5) is completely defined by its interface - every two components
exposing the same interface are completely replacable, and basically
indiscriminate for user
It is important do make distinction between objects and components here,
failure to do so leads to misguided attempts like CORBA. Although
objects and components may look similar (both have methods and
interfaces, both encapsulate some kind of underlying structure into
useful abstraction), they are very much not alike. Objects are
interdependant, interact on many levels, and cannot be generally treated
like black boxes. Following useful example by ObjectWatch.com (otherwise
pretty hate-filled scum, but this one they got right), component is like
clerk at shop. Clerk interacting with customer is loosely coupled, is
fully separated from outside, all interaction is done purely on basis of
interface exposed by clerk. Also two clerks are completely replacable.
Example of objects may be clerk's stomach and heart. Main difference
between these cases is that for customer, details of clerk's working are
completely uninteresting, while for heart, stomach's working is very
important. Also, although clerk internally has stomach and heart, for
customer it wouldn't make any difference if he was ATM, and in fact
consisted of CPU and RAM. Clerk is fully defined by interface.

Now, why is D-BUS useful for components system? It meets all
requirements above:

1) It forces loose coupling - all interaction via DBUS is by its nature
loosely coupled, there is no way for sender and receiver of DBUS message
to get into any more intimate relationship

2) Provides clear separation - there is no way to use DBUS other than
explicit interaction, following defined interface

3) Obviously, all objects visible by DBUS expose interfaces

4) Interfaces are complete (provided they are properly defined, of
course). Since we cannot bypass deficient interface, it necessarily
needs to cover all needed interactions

5) DBUS objects are fully defined by interfaces - since there is no
other information available than interface along with service and object
path, there is also no way to discriminate between two implementors of
given interface

Other reasons why DBUS is good:

7) It is not evil. Contrary to CORBA / COM, DBUS is right from the very
beginning defined as to what it is supposed to do, and has clear scope

8) It's simple and small - DBUS isn't anything more than it is. It does
only one thing, namely provides transport mechanism, and does it well.
It is really easy to use, too

9) It doesn't try to drag other concepts along. It doesn't pretend to be
object-oriented be-all end-all, doesn't try to be transparent, does not
try to abstract to the point of overgeneralization

10) Is not too low level, nor is it very high level, it's just right

11) It doesn't try to be type system - DBUS allows for exposing types,
but does not try to define them. No inheritance, no IDL. Also it doesn't
doesn't pretend to cover types system of full-fledged programming
language. We don't transmit structs over wire for a reason

12) Does not pretend to be transparent. This single mistake made by both
CORBA and later DCOM is enough to outweight any possible advantages ;)

To make myself clear, I'm not proposing DBUS to be component system.
That would destroy reason 8 above. Instead I am proposing DBUS as a
foundation of one. Of course, implementation of in-process components
would need to be different from out-of-process one, and there would be
very clear distinction of whether we are using in- or out-of-process
components (reason 12 above). But IMHO, there is no reason, why
_semantics_ couldn't be the same. Together with enhanced GObject system
(for easy creation of components, with full introspection etc.) it could
create components that doesn't suck and Just Work(TM) :)

What do you think. Am I smoking crack? Am I totally insane?

Cheers,
Maciej

PS. Despite the looks, I'm not trying to troll :). I'm just very excited
about DBUS, and want it to succeed as much as possible. If I ever become
another oGo, please, kick me right away ;)
-- 
"Tautologizm to coś tautologicznego"
   Maciej Katafiasz <mnews2 at wp.pl>
       http://mathrick.blog.pl