cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephan Michels <step...@apache.org>
Subject [RT] JSR170, Slide and AOP
Date Thu, 17 Apr 2003 07:01:38 GMT

Hi,
these are my first random thoughts in this list, so excuse me, if
these RTs doesn't have the same qualitity of other RTs. Yesterday I
have been ask for the reason, why I think that the current proposal
for the JSR170 API within the Slide repository is
'ugly'(this mean only the design not the implementation). Now, I
want to explain my point of view.


VFS, Excalibur Source
=====================
There exist two different ways to implement a access to such a thing
like a 'content repository'. The first way follow implementations like
VFS, Excalibur Source and now the proposal for JSR170. These
implementation mixed model and logic. For example, I want to create
a new file, so I must use the following pseudo code:

 File file = Resolver.resolve(path);
 file.create();
 String path = file.getFileName();

So what is wrong with this code. You have here mixed model and logic.
The problem with this example, it will explode, if you add more and
more aspects, like versioning, locking, ACL's, searching etc. So at the
end you will have a candidate for the FS(fexibility syndrome), with dozen
of methods for every aspect. On the other side, you will have the problem
with 'poor mens'-repositories, which doesn't have all such aspects. One
way to solve such a problem is to capsulate the aspects into
interfaces, like

 * Restrictable
 * Versionable
 * Lockable
 * etc.

But you have neverless the problem, if you implement all these
aspects, you will have big classes with a big memory footprint.

So are there alternatives? Yes, there are! The Slide API. What
make the Slide API different?


Slide API
=========
The Slide API have for every aspect a separate helper class, or
component. For example, if you want to lock a file, you can use the
following pseudo code:

 locktoken =  new NodeLock(lockSubject, lockDate);
 lockhelper.lock(slideToken, lockToken);

Here we have a totally separation of model and logic. The client
comunicates with component over the model. You don't have any
logic in the model. This design allows a better scaling, because
if you add a aspect, you simpliy add another component. And also
the fact that you don't have a model within the component helps.
So most components can be written threadsafe, and you need only
one instance.

And this is Aspect Orientated Programming for me.

I also made these faults in the past, and then I must learn it the
hard way, but anyway this is only my opinion.


Enhancements
============

The Slide API is not perfect. You can't easily exchange the
implementation for the components, except for the stores. I
would love to see a avalonzied version of Slide, and I think
others too. There is a resemblance to the interfaces from
the Avalon project, with some adapter classes, I could easily
integrate the Slide API into a Avalon container.


Thank you for your attention, Stephan Michels.

_______________________________________________________________________
         Stephan Michels               EMail: stephan@apache.org
         ICQ: 115535699                Tel: +49-030-314-21583
----+----|----+----|----+----|----+----|----+----|----+----|----+----|-|


Mime
View raw message