Jason,
I don't see why not, the general idea is the same. Maybe there should be an
org.apache.services package and a separate repository for this sort of
thing? The kind of thing where Turbine and Struts committers can both
participate?
If there was collaboration, I'd prefer it not to be Struts or Turbine based.
A framework where the community at large decides on how the interface
methods are declared would be a powerful thing, and shouldn't be interfered
with because different design methodologies for web applications cause
different projects to exist. I mean, this is open source.
-----Original Message-----
From: Jason van Zyl
To: '[EMAIL PROTECTED] '
Sent: 2/19/01 7:21 PM
Subject: RE: i18n and Resources
> I hate the fact that the word "service" is so overused, but in this
context
> it would be an implementation of an interface residing at the request
scope
> of an application.
>
> I'm still pushing for a lightweight, application level service
framework
> within Struts, I'm just working on a proof of concept and some real
code
> before I go and introduce anything, probably not a great move
community-wise
> on my part.
>
> For people unfamiliar with the service framework I'm talking about,
> basically it's a set of standard interfaces for common application
> functionality such as localization, device detection, object pooling,
etc.
> The most common functionality would be included with implementations
with
> Struts, more time-intensive implementations could hopefully be
represented
> as a set of plugins/adapters for commercial vendor products that
provide
> that functionality.
There is already a functional services framework in Turbine, is
there anyway we could work together on this?
jvz.
