avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <blorit...@citi-us.com>
Subject [A5:Proposal] Initial interfaces
Date Fri, 03 Jan 2003 14:58:40 GMT
I believe that we can simplify A5, and make it work within the
confines of J2ME.  I am working with the RT that I put out before
on reducing the complexity of implementing a component, tempered
with some of the input I received last time.

Enclosed is a zip file that has all that is required (including
a skeleton Centipede build environment--as long as you install
it separately all will be well).  The first thing you will notice
is that it is small.  Secondly, you will notice that there are no
implementations--that is later.  Thirdly, the largest debate will
center around the Context object.

I separated out the Logger from the context object because there
are many instances where you may want logging, but don't need any
resources or configuration.

The context provides a unified namespace for all the resources that
a component could want.  That includes components, configuration
information, and other resources.  It includes a "query" method to
determine if a resource is available (to support optional components).
It also includes a "rebind" method to change the value of a context
entry.  Some environments (like J2ME or sandboxed components) will not
support it, so the context will throw a SecurityException.  The
rebound object must have the same type of object to successfully
bind the value.  I.e. configuration for configuration, etc.

As to what happened to Configuration/Parameters, I don't think that
they are needed with this arrangement.  If all resources are bound to
a name (URN), then looking up your configuration object to look up
your value is not only redundant but it is also much slower.  It will
also alow us to play with many different options for configuration.

If these interfaces provide a nice balance between separation of
concerns and fragmentation of concerns, we can further discuss the
contracts of each stage as necessary.  Let's keep an eye on making
this really easy for component developers.

View raw message