Michael Wechner wrote:
[...]
sure. No offense, but if Lenya isn't able to do this, then Lenya is
pretty useless. If Lenya doesn't allow building a Forrest publication,
then I think we have totally missed the goal of providing a Content
Management Framework
I don't think that we will be able to support all existing content
storage mechanisms.
the framework should be flexible enough that one is able to implement
it's own content storage.
You can - by implementing a JCR content repository.
Another possiblity is to create an abstraction above JCR which
provides all functionality JCR offers that we might need.
But as we don't know yet which requirements we'll need in the
future, that would mean to make assumptions. Anyway, you'd have
to mimic a lot of functionality in your repo implementation
(or throw a lot of OperationNotSupportedExceptions).
We should be careful not to lose ourselves in
flexibility. We can't foresee all scenarios anyway.
Flexibility doesn't mean we have to implement all scenarios, but
provide interfaces which allow various scenarios. I guess the minimal
interface would be
InputStream getInputStream
OutputStream getOutputStream
This is a tiny bottleneck. Why use JCR at all? The filesystem provides
this functionality without the JCR overhead.
A framework is not a Swiss army knife.
why not?
I referred to the SwissArmyKnife antipattern (whereas the term is
not entirely appropriate, as stated here: http://c2.com/cgi/wiki?SwissArmyKnife)
But the following passage explains what I mean:
<quote src="http://c2.com/cgi/wiki?SwissArmyKnife";>
Often used as an idiom for a tool that does lots of things "acceptably" well
(for some level of "acceptable"), though it does nothing optimally. With a real
Swiss Army knife, one can trim or file one's nails, cut through things, turn and
drive screws, remove a cork from a wine bottle, and open a can; though one could
do each of those tasks much more easily with a separate nail clipper, knife,
screwdriver, corkscrew, and can opener.
</quote>
IMO building a framework means providing a base to simplify the development
of complex applications by *reducing* flexibility. The implementor is forced
to use certain patterns, concepts, and components that proved useful for certain
types of applications.
For special scenarios, special solutions can be found.
In the case of Forrest - how about implementing a custom generator
which provides a read-only view of the Lenya repository which resembles
the Forrest file system?
I think Lenya should be able to read and write to Forrest. Again no offense
and please apologize for sounding harsh, but I think if Lenya is not able
to provide such interfaces it's really useless.
OK, I see your point, and some time ago I would have agreed to 100%.
But in the meantime I got some experience what it means to implement
funtionality of a content repository, and that's rather not a piece of cake.
Our community is quite small, I'd say we shouldn't trade stability,
robustness, and maturity for virtually limitless flexibility and optional
customization - at least not when it's about the very heart of our
application.
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
