Rafal Krzewski wrote:
>
> Jason van Zyl wrote:
>
> > I would like to start a discussion on the feasibility
> > of turning Turbine services into plugins, or blocks to
> > to use Avalon terminology.
> >
> > The basic idea would be to have a directory where service
> > plugins are picked up when a Turbine application is
> > started. We would have to deal with dependencies among
> > services and configuration issues, but I think we could
> > borrow a lot from Avalon as this concept is already
> > implemented and working in Avalon.
>
> Hell, I have no idea what is the problem here.
>
> Turbine services are perfectly pluggable as of today.
> If your code depends on the service interface or the facade class
> you can swap the implementation of the service changing only TR.props
> file.
> I thought that it was a really obvious fact, so I'm surprised that
> nobody on the list reacted.
>
> And yes, we are able to deal with service dependencies, no problem.
>
The issue is that services are pluggable only within Turbine but
not easily usable by projects outside of Turbine (like Cocoon
for example).
The goal of Avalon is to create an API that enforces low coupling
between "components" (and "blocks") so that cooperation between
components and/or blocks can be decided at run-time.
Making TurbineServices compatible with Avalon components would
allow Avalon based project to use Turbine services and make
some Avalon components available as Turbine services, hence
expanding the pool of quality common utility code available for
all the projects (even though they're still a lot more of
Turbine services than Avalon components/blocks).
While the TurbineServices framework itself should be pretty easy
to adapt to be compatible with named Avalon components, there are
a lot of difficulties to make Turbine services available as
Avalon components.
A lot of current services were historically integrate part of
the Turbine framework (and Turbine depended on a specific implementation).
The API of these Services is still tightly coupled with the rest
of the Turbine framework (it's the whole RunData issue).
To sum up:
adapting TurbineServices to use Avalon components should be pretty easy
without major refactoring
adapting existing Turbine services as Avalon components will most often
require major API changes
--
Raphaël Luta - [EMAIL PROTECTED]
Vivendi Universal Networks - Services Manager / Paris
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
