I am the main coder of the databus/FreeBASE (based on a design by Curt
Hibbs) so I will give this a shot.
Hi,
I’ve been looking into FreeRIDE and I’m quite impressed
especially of the design of it all. It uses a DataBus
of hierarchical “ports” as a kind of generalized event
system.
I’d like to know some more about this type of design. I’ve
read most of the info at the rubyide.org site but would like
more info about the motivations etc behind the design.
So if there are any FreeRIDE developers (or others) out there
please answer:
- Why did you chose to base FreeRIDE on the DataBus design?
We needed a plugin architecture (a la Eclipse) and we wanted to build
the IDE such that there was a separation between the model of
components of the IDE and the rendering of those components. I signed
up to build that architecture. At first it was based on UI
abstractions, but we needed something that also served as an
abstraction for plugins in general (visual or non-visual). The databus
served both of those purposes and Curt and I iterated the idea (in
code) over a couple of day period. In Curt’s prior implementation he
stored the layout of the UI components in the hierarchy of a databus
(such as list of items in a listbox) and had a renderer “subscribe” to
that path in the bus. When the slots in the bus were changed
(published) it would notify the subscribers and be rendered. So, the
database is essentially a publish & subscribe system (a la
Linda/Tuplespaces) but the introduction of a hierarchy is interesting
because it lends itself to a “contains” relationship which meets many
real-world problems (UI’s being one of them). If you subscribe to a
certain level you will be notified of everything under that level
(events ‘roll up hill’).
The databus itself is just the publish/subscribe manager. The actual
plugin system which wraps around it (collectively named ‘FreeBASE’)
allows the databus to serve as a generalize foundation for building
plugin-based applications. FreeRIDE is just one such application. I
actually use FreeBASE on my project at DARPA (US DOD/Research). It has
nothing to do with FreeRIDE per se, but leverages the same
infrastructure. A plugin system’s main job is enabling the management
of plugins dependencies (one plugin needs another to work) and
communications via an abstraction.
One interesting capability available to Ruby was the mounting of
blocks/procs in databus slots…not just data. This enables the
binding of behavior (a higher level ‘method-binding’) and not just data.
- What are its main benefits?
We can create renders in different UI frameworks for the underlying
implementation of FreeRIDE. We currently use FXRuby, but could easily
support other UI libraries.
Creating new plugins is really simple (about 10 or so lines of code)…
Take THAT Eclipse 
Its reusable…always good.
Composite behavior:
editpane/actions/parse → bound to a method on the parser plugin’s
object (currently Ripper)
editpane/actions/cut → bound to a method on the renderer plugin’s
editor object (currently Scintilla under FXRuby)
So the single abstraction (editpane) has behaviors connected to it
through multiple plugins
- What are its main drawbacks?
It increases the complexity of your code somewhat because you are
referencing things through an abstraction rather than directly. It
can get out of hand if you don’t balance putting objects in slots
(and calling methods on them) vs. creating slots which (via procs slots
and data slots) undate objects through indirection. The simple way is,
of course, just dropping the object in the slot, but then you lose the
abstraction of notification when attributes of the object change or you
want to ‘composite’ different objects together to implement a behavior.
Speed…have a level of indirection always effect speed, but this is
mitigated somewhat through the hierarchy. All subscribers don’t have
to be notified of all publications (only those located ‘below’ the
subscription point).
- Any links to info on related designs/principles?
curt@hibbs.com
Seriously…this code evolved through use based on collective
experience and need.
I am sure there is a lot of existing designs/principals covered here
that can be referenced…I just don’t know them 
-rich
···
On Thursday, February 13, 2003, at 09:42 AM, coma_killen@fastmail.fm wrote: