From: John Morrison (jmorrison_at_ahc.net.au)
Date: 2002-02-27 14:44:57
> I'm a bit confuseled about this "plug-in" idea. In my
> view there is a difference between object-oriented
> code (objects/classes), component-based architectures
> (Java Beans and COM/OLE/etc), distributed components
> (EJB/DCOM), and plug-ins.
Sorry plug-in was a term someone else brought up.
That is why I was saying Modules!
> frameworks can be a path to complexity. I've seen
> some pretty huge and ugly frameworks out there.
So have I. Windows, Linux, etc :-)
> Adding the ideas of distributed components and/or
> plug-ins seems to be a bunch of complexity that we
> don't need. Even components are questionable, it's
> not like this system is going to be reconfigured
??? Why not ???
> in many different ways (the whole idea behind
> components is assemly in a GUI tool where you
> "snap together" components). It takes a LOT of
> work to build a good component-based system.
Components IS the way I'm pointing!
Forget about the GUI for starters and use just a flat configuration file
(Connect output 1 to input 3, etc)
The Main Program loads all of the modules need for the particular
application, connects output to inputs and the application starts.
In Java it's trivial as each class is a separate file and after extantiation
is treated as any other object.
Can we do the same in C++ or does it have to be recompiled to include new
classes??
> So that leaves good old object-orientation. I don't
> see why we need to go further than this. Planning,
> therefore, IMO is making a good set of object
> classes and interfaces. What I am most concerned
> about is the abstracting of layers so that the GUI
> is not tied directly to the FFT or the input or
> the coniguration details. As I mentioned before,
> I think something along the lines of the
> model-view-controller design pattern would work
> nicely for this. What we end up with is a set of
> APIs, call it a framework if you want, that is
> just a buzzword for APIs. It would also be easy
> to add distributed (networking) features by
> just extending the API.
I'll have to re-read MVC systems but sounds right!
I think Hardware, filtering/processing and display should all be separate
with a high degree of abstraction between them!
I think networking should be left as a module not made part of the API!
> Component based systems, especially distributed
> ones, tend to be hairballs. CORBA is a hairball.
NO don't even mention COBRA.
> Again, planning is goodness, but let's don't
> make another browser, DCOM, or CORBA. Clever
> programmers make clean and simple and small systems.
Just remember we aren't just programming for people that can program and do
it all themselves.
Maybe we should do a poll and see who programmes on here!
We maybe programming for the people that use EEG, NF programs in a clinical
or healing environment. Most of these wouldn't be able to recompile and
customise a program to do what they want it to do.
So we would have to build every hardware module and display type that they
MAY want to use into the program, that is going to make one blotted bit of
software (IE Netscape with all the bells and whistles). :-(
But using components they will only load the components necessary to run the
particular protocol they want to run. IE much smaller memory foot print.
OK Components maybe a pain but we are DESIGNING components with a VERY
limited interface to the system and each other. WE don't want to write a
CORBA and it doesn't have to know anything about distribution. Doesn't this
simplify the problem considerable???
> -- Doug
Awaiting your replay
John
This archive was generated by hypermail 2.1.4 : 2002-07-27 12:28:39 BST