From: Richard Kilmer <rich@...>
Date: 2003-02-14T00:47:20+09:00
Subject: Re: FreeBase/Databus design of FreeRIDE

I am the main coder of the databus/FreeBASE (based on a design by Curt 
Hibbs) so I will give this a shot.

On Thursday, February 13, 2003, at 09:42  AM, coma_killen@fastmail.fm 
wrote:

> 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