From: Doug Sutherland (wearable_at_earthlink.net)
Date: 2002-02-28 03:31:56
Hi Moritz,
> I think this whole idea is about the END USER being able to
> connect system parts in various different ways. That's how
> you design a protocol !
Hmmm ... well I agree that system parts should be able to
be connected dynamically (through configuration), but as
I have said in many words, forcing them into components
is not necessarily a good idea.
> The end user should be able to draw (like in LabView)
> the protocol (=connection of different components + some
> parameters) by himself.
Okay, but this can be just a GUI referecing objects, they
don't have to be components. I've played around with the
whole component idea (COM/OLE/DCOM/ACtiveX/JavaBeans and
OpenDoc etc etc). They have their place. I don't think
they are needed for 'software modules' in a system like
this.
> assemble it with a graphical editor (next step, after the
> framework is working). This is much more flexible then
> the current approach where all you can do to change the
> protocol is change some parameters.
Agreed. This is what I want to do with wearable interfaces.
> How this is achieved and how it's called, module or
> object or whatever, isn't important.
Right. But OTOH if we strive for true 'snap together'
interfaces we lose a lot of flexibility in the process.
They can still be traditional object classes, existing
in a heirarchy, with or without abstract interfaces,
and be connected together (in, processing, out) in a
GUI without being components.
If I create an interface to a device, like my infrared
remote control, I purposely create abstract interface
that defines ONLY the methods. Implementation of those
methods is really independent of the process. And it
tends to change over time, to different tech etc.
Take the input interface for example, we have talked
about different methods/protocols: RS232, USB, IR,
wireless, etc. An ABSTRACT interface will ignore the
underlying method/technique but force behavior. This
kind of abstraction makes a lot of sense for OpenEEG.
But true components don't allow abstract interfaces.
They don't behave like objects esp polymorphically.
What I'd like to see a focus on object model, to get
that right first (classes, methods, interfaces). Then
some work on design patterns, interactions between
these objects. Things will look very different if it
is OO versus components. You could make all of these
EEG functions into Java Beans or ActiveX controls or
OpenDoc containers etc. But it's a trade-off, and the
gain may not be worth the loss in flexibility.
-- Doug
This archive was generated by hypermail 2.1.4 : 2002-07-27 12:28:39 BST