#14 architecture bugs (modularity & contracts api)

open
nobody
None
5
2003-09-17
2003-09-17
Anonymous
No

Ok. Sandstorm is composed of 4 main sections:

-The Stage management module, which is responsible for
creating stagewrapperIF implementations.
-The thread management module, which is responsible for
registering stages and running them.
-the profiling module, which offer registration for any
kind of metrics.
-the signaling module, which offer a signal bus.

There was an obvious intention of makig those module
pluggable (as internal api is concerned, granted).

Some remaining problems to reach that goal:

-the signaling bus is using the queue of stages,
without possibility for prempting the data, and it is
lossy enqueued, which is unacceptable for signaling. It
should be on a separate control bus.

-the profiling is very taxing if profilables
registration are not filtered (everything would be
probed). Adding a profilable may not be filtered, but
its probing should be conditionnal.

-the stage creation is handled partly by the system
manager, which is ok, I guess, for the default
stagewrapper flavor, but not convenient for other stage
implementations (internal api), like aFile and aSocket.
They have to rebuild all the stagewrapper contract
interfaces (sink, stage, source, etc... Although they
internally reuse core classes, nothing enforces good
implementation. It should only delegate precise stage
contract by some visitor/proxy pattern)

-the default stage creation does not have the choice of
the thread manager it wants (it uses the default one
chosen by sandStormMgr (which is not even created
through Class.forName). It should use registered
threadmanagers through
SystemManagerIF.getThreadManager(String tmname)). stage
management implementations could choose the thread
manager they intend to use in the container.

Discussion

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks