Graham Fawcett wrote:

> I do think componentization is a good thing. For example, it would be
> very nice to have a well-designed User Management component that could
> be embedded in an application, and/or shared among multiple applications
> on a server. Reinventing user-management interfaces for each application
> seems like a waste of time. It's hard to write one that meets everyone's
> needs; but it would be a worthwhile undertaking to try. The mere
> existence of such a (well-conceived) module should motivate designers to
> use it, or imitate its interfaces (user and/or back-end); either way we
> begin to settle upon a User Management Interface that would do for
> user-management what the WSGI work on the Python Web-SIG promises to do
> for Web-server connectivity: add interoperability and reuse at the edges
> of our applications -- not where our app logic is, but where the boring
> stuff happens.
>
> I hope we haven't lost touch with the initial idea of building an Issue
> Manager in Quixote; and I also hope that all this talk of components
> hasn't introduced "analysis paralysis" to anyone who had begun sketching
> a system. I just hope that we can *eventually* factor out the boring
> stuff (database, mail delivery, user management) into modules/components
> that have well-grown interfaces, so that other parts can be substituted
> if the need arises.
>
>> Is there something I'm missing out of and there are some killer use
>> cases that demonstrate how containers make the solution of problems
>> actually easier than doing without containers and framework?
>
> Until a container can abstract persistence to the point where I don't
> care if it's Oracle, ZODB or a set of text-files on the back end of my
> application (never, perhaps?), I suspect that their usefulness is
> limited largely to separating configuration from logic. And that can be
> done without containers.
>
> Best,
>
> -- Graham

I agree with you on most points. In fact I have been motivated by similar
factors to try and design componentized additions to Quixote. However if
applications want to be portable across data sources, they have to be
written to one defined interface and then are limited by the different
implementations available for that interface. This is still a step up from
something like Zope, where applications written for ZODB cannot be
(easily) ported to relational databases.

I think that a data persistence interface by itself could be used
*instead* of components with pre-defined interfaces. For examle, instead
of having a user management component that implements an interface (i.e.
an API consisting of a bunch of methods), there could just be a user 'data
schema' (i.e. consisting of a set of objectclasses each consisting of a
set of attributes).

Now any application such as an issue tracker uses the standard persistence
interface to add and read user and group information. When someone wants
to deploy this application, he simply points it to the correct objectclass
in his environment, that may be implemented over any data source. Now you
have a new application working with *existing* data. In fact there might
be a separate application that adds and deletes users so that function of
the issue tracker may be turned off by configuration.

Taking the idea further, the schema doesn't even have to be pre-defined.
During deployment, the deployer may *create* a new objectclass from
existing ones simply by configuration (specifying joins, mapping attribute
names etc.). This new objectclass now exposes the correct schema for the
new application and they can be tied together.

Sorry for going on and on, but I think the idea I am trying to push is to
use a data-oriented approach rather than an interface-oriented one. With
interfaces, you always need a pre-written component that implements the
correct interface. With data, it may be possible to construct the correct
objectclass on the fly to suit your application.

Cheers,
Shalabh