[openbeosstorage] Re: latest update

On Sat, 27 Apr 2002, Tyler Dauwalder wrote:

> 
> > I was thinking about turning EntryRefToPath into an add-on. Then it
> > would be even easier to add other functions (if we need any).
> > What do you think?
> 
> How were you planning on doing it? I'd thought about rewriting it to be a 
> daemon that communicated via ports, but I never got around to it.

An add-on should be the easiest to implement and best performing solution.

I don't know, if you're familiar with add-ons. If not, here are the
basics:

* An add-on can be compared with a shared library: It can implement
  arbitrary functionality and may be linked against any libraries.

* But unlike a shared library, an add-on is not linked against the
  application that likes to use it (unless the app provides
  functionality that needs to be used in the add-on). The app has to
  explicitly load it via load_add_on() and retrieve pointers to the
  functions it likes to invoke via get_image_symbol().

* As it is quite inconvenient to get every single function pointer by
  hand, The Be Way (tm) is to provide an abstract base class XYZAddOn, and
  let the add-on create an instance of a derived class via a method
  create_xyz_add_on(). XYZAddOn provides a collection of all functions the
  application wants to use and the derived class in the add-on implements
  these. Thus only one function symbol needs to be retrieved.

Our add-on will be linked against libbe, but the application
(Test.StorageKit.OpenBeOS) won't.

At this time, we have only one external function, so we might implement
it in the add-on and just get the pointer to it via get_image_symbol().
In this case the add-on will look really compact (ten line or so).

Doing it The Be Way (tm), we would need a shared lib containing the
abstract add-on class, because both the application and the add-on need to
use this code, but the add-on must not be linked against the app due to
libbe.so+libstorage.a name clashs.

CU, Ingo

Other related posts: