You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by Michael Wechner <mi...@wyona.com> on 2006/04/01 22:49:52 UTC
Re: [Proposal] Moving components configuration to the resource type
API
Andreas Hartmann wrote:
> Michael Wechner wrote:
>
>> Andreas Hartmann wrote:
>>
>>> Michael Wechner wrote:
>>>
>>> [...]
>>>
>>>>>> which I think should apply for all "components" working on resource
>>>>>> types:
>>>>>> Creator
>>>>>> Editor
>>>>>> Indexer
>>>>>> Publisher
>>>>>> LinkRewriter
>>>>>> ....
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> If we allow this, we would also need a resource-type specific Mover,
>>>>> Copier, Deleter, Deactivator, Revisioner, ...
>>>>>
>>>>
>>>> similar to the source interface ;-)
>>>
>>>
>>>
>>> It's not really similar. The source interface is a single entry point
>>> to access resources using a protocol. There are no cross-connections
>>> if you use the concept consequently (i.e., always use the protocol and
>>> therefore the source implementation to access these resources)
>>>
>>> The components mentioned by Josias have multiple cross-connections.
>>> Providing a specific implementation for one of them requires to
>>> provide implementations for the others as well.
>>
>>
>>
>> I don't fully understand. Can you give an example?
>
>
> Imagine a resource type which uses a binary source and an XML source
> for a document.
>
> If you allow this, you have to
>
> - implement a Copier which copies these two files
> - implement a Revisioner which backs up / restores these two files
> - implement a Deleter which deletes these two files
> - ...
right
>
> If you use two Lenya documents, and use the (not yet existing)
> reference mechanism to link from the primary document to the
> secondary document, the internal Copier, Revisioner, and Deleter
> components will be able to handle this just by following the
> references if this is desired.
which I would consider a very helpful implementation, but it shouldn't
be confused with the API.
> You could maybe compare this with
> the onParentVersion functionality of JCR.
>
> [...]
>
>>>>> But if we allow that a document may be "anything", and only the
>>>>> resource
>>>>> type knows what it is, the complexity seems to grow quite a lot (of
>>>>> course the flexibility would increase, too). It might also lead to
>>>>> duplication of knowledge if each resource type has e.g. its own
>>>>> publisher.
>>>>
>>>>
>>>>
>>>> you can always provide default implementations
>>>
>>>
>>>
>>> But that doesn't reduce the complexity.
>>
>>
>>
>> I think it does. In probably most cases you don't have to implement
>> it yourself
>> but pick an existing one
>
>
> I didn't mean the complexity of a single implementation, but
> the complexity of the API (I'm not sure what Josias meant).
>
> The more implementation options you want to give to the integrator,
> the more difficult it will be to design a comprehensible and
> maintainable framework.
it's not that complex. We already have everything, but we need to
abstractize it just as JCR is an API working on nodes and properties
instead working on directories and files ;-)
>
> Another issue is the communication between components. You have
> to find a "least common denominator" to design interfaces. If
> you want to allow polymorphism for a family of components which
> operate on the same data, you're likely to end up with the
> MagicContainer antipattern (see the Creator interface). And IMO
> a ParameterObject should not be used fo inter-component
> communication.
>
can you give an example here as well?
>
>>> If implementing a custom
>>> resource type means to implement all these mentioned components,
>>> it means to virtually implement a document management system for
>>> each advanced and complex resource type.
>>
>>
>>
>> yes, but what is the alternative?
>
>
> IMO the reference concept is sufficient to fulfil the requirements
> mentioned until now.
maybe it is, maybe it's not. My experience tells me that everytime one
thinks one has now covered all usecases, a new usecase pops up.
Off Topic: for instance I think the 1-to-1 mapping of "lenya meta files"
is not
sufficient as it is today, because for instance the usecase of dynamic
URLs, e.g.
the timestamp, or proxy requests are not covered, but can only be covered by
allowing more general patters after the 1-to-1 mapping.
>
>> And as said above I don't think that's a problem
>> because of the argument above. Also one can offer tools to simplify
>> the process, just as
>> for instance there are tools to create XML Schemas, etc.
>
>
> Well, IMO the major problem is that it is much harder to achieve
> stability and backwards compatibility when the API becomes more
> complex.
as said, I don't think it's more complex, but less specific, whereas
in most problems maybe one specific implementation can be used.
I understand the difficulty to abstractize, because it took me for
instance a long
time to understand how specific polynomials can form a vector space:
http://en.wikipedia.org/wiki/Examples_of_vector_spaces
http://en.wikipedia.org/wiki/Vector_space
but recognizing it in the end will solve a lot of problems very quickly.
And I think recognizing the generic API and providing implementations
(as the by you mentioned reference implementation) will make things very
simple in the end.
Michi
>
> -- Andreas
>
>
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
+41 44 272 91 61
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [Proposal] Moving components configuration to the resource type
API
Posted by Andreas Hartmann <an...@apache.org>.
Michael Wechner wrote:
> Andreas Hartmann wrote:
>
>> Michael Wechner wrote:
>>
>> [...]
>>
>>>> If you use two Lenya documents, and use the (not yet existing)
>>>> reference mechanism to link from the primary document to the
>>>> secondary document, the internal Copier, Revisioner, and Deleter
>>>> components will be able to handle this just by following the
>>>> references if this is desired.
>>>
>>>
>>>
>>> which I would consider a very helpful implementation, but it shouldn't
>>> be confused with the API.
>>
>>
>> What do you mean with "confused with the API"?
>
>
> that the implementatio is becoming the API
What do you mean with "implementation is becoming the API"?
Both ways are possible - either you design an API and build
an implementation, or you have a proven implementation and
extract an API from it ...
>> It would be part of the API:
>>
>> Document.addReference(Document, int referenceType)
>> Document.removeReference(Document)
>> Document.getReferences()
>
>
> that's exactly what I think shouldn't be. This "reference
> implementation" shouldn't
> be the API, but maby I misunderstand something completely ...
How could you tell Lenya about references if reference
handling is not part of the API? The API is the interface
to communicate with Lenya - everything you can do must
be exposed through the API.
[...]
>> Imagine you have a JCR-based repository implementation.
>> Then your Copier interface might look like this:
>>
>> Copier.copy(Document src, Document dest, javax.jcr.Session session)
>>
>> In a RDBMS-based implementation, it might look like this:
>>
>> Copier.copy(Document src, Document dest, DBConnection conn)
>>
>> In a file system based implementation, it might look like this:
>>
>> Copier.copy(Document src, Document dest, File contentDir)
>>
>> And so on.
>
> that should be hidden by the (resource type) persistance manager
Sure, you can sum up the copying, versioning, ... into a
persistence manager interface, but that doesn't change anything
but terminology.
>> But if you want to export the Copier interface in the API,
>> you have to provide a generic parameter passing mechanism,
>> e.g. with a ParameterObject:
>>
>> Copier.copy(Documetn src, Document dest, RepoInformation info)
>>
>> That's not elegant at all.
>
>
> I think it should be
>
> Copier.copy(ResourceType src, ResourceType dest)
>
> resp.
>
> Copier.copy(ResourceTypeID src, ResourceTypeID dest)
??
Why do you want to copy resource *types*?
We're handling documents (resources), not resource types.
Or have I totally lost track? :)
>> BTW, this brings up another problem if we allow multiple repo
>> implementations:
>>
>> If you want to allow custom Copiers, Revisioners etc. for different
>> resource types, you end up with (resource types) x (repo impls)
>> implementations, e.g. a
>>
>> XhtmlJcrCopier
>> XhtmlFilesystemCopier
>> ...
>> OdtJcrCopier
>> OdtFilesystemCopier
>> ...
>>
>
> right, but I don't see a problem with it
Well, I wouldn't like it :)
What do the others think?
[...]
> right now every URL needs a Lenya meta file (1-to-1 mapping), e.g.
>
> calendar.html is being mapped to calendar/index_en.xml.meta
>
> but what if you have a proxy resource type for instance
>
>
> proxy/** --> proxy.meta (???)
>
> any you don't know what URLs are actually being available, then a
> wildcard rule help or
> if you have URLs like
>
>
> time/45654645656.html (time/**) ---> millis.meta
OK, thanks for explaining.
I guess that would need some new concepts in Lenya.
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
andreas.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [Proposal] Moving components configuration to the resource type
API
Posted by Michael Wechner <mi...@wyona.com>.
Andreas Hartmann wrote:
> Michael Wechner wrote:
>
> [...]
>
>>> If you use two Lenya documents, and use the (not yet existing)
>>> reference mechanism to link from the primary document to the
>>> secondary document, the internal Copier, Revisioner, and Deleter
>>> components will be able to handle this just by following the
>>> references if this is desired.
>>
>>
>>
>> which I would consider a very helpful implementation, but it shouldn't
>> be confused with the API.
>
>
> What do you mean with "confused with the API"?
that the implementatio is becoming the API
> It would be part of the API:
>
> Document.addReference(Document, int referenceType)
> Document.removeReference(Document)
> Document.getReferences()
that's exactly what I think shouldn't be. This "reference
implementation" shouldn't
be the API, but maby I misunderstand something completely ...
> ...
>
> [...]
>
>>> The more implementation options you want to give to the integrator,
>>> the more difficult it will be to design a comprehensible and
>>> maintainable framework.
>>
>>
>> it's not that complex. We already have everything, but we need to
>> abstractize it just as JCR is an API working on nodes and properties
>> instead working on directories and files ;-)
>
>
> Yes - the Lenya API should support working on documents.
> But a custom copier, deleter, ... would have to operate
> "behind the scenes".
>
>
>>> Another issue is the communication between components. You have
>>> to find a "least common denominator" to design interfaces. If
>>> you want to allow polymorphism for a family of components which
>>> operate on the same data, you're likely to end up with the
>>> MagicContainer antipattern (see the Creator interface). And IMO
>>> a ParameterObject should not be used fo inter-component
>>> communication.
>>
>>
>> can you give an example here as well?
>
>
> Imagine you have a JCR-based repository implementation.
> Then your Copier interface might look like this:
>
> Copier.copy(Document src, Document dest, javax.jcr.Session session)
>
> In a RDBMS-based implementation, it might look like this:
>
> Copier.copy(Document src, Document dest, DBConnection conn)
>
> In a file system based implementation, it might look like this:
>
> Copier.copy(Document src, Document dest, File contentDir)
>
> And so on.
that should be hidden by the (resource type) persistance manager
>
>
> But if you want to export the Copier interface in the API,
> you have to provide a generic parameter passing mechanism,
> e.g. with a ParameterObject:
>
> Copier.copy(Documetn src, Document dest, RepoInformation info)
>
> That's not elegant at all.
I think it should be
Copier.copy(ResourceType src, ResourceType dest)
resp.
Copier.copy(ResourceTypeID src, ResourceTypeID dest)
>
> BTW, this brings up another problem if we allow multiple repo
> implementations:
>
> If you want to allow custom Copiers, Revisioners etc. for different
> resource types, you end up with (resource types) x (repo impls)
> implementations, e.g. a
>
> XhtmlJcrCopier
> XhtmlFilesystemCopier
> ...
> OdtJcrCopier
> OdtFilesystemCopier
> ...
>
right, but I don't see a problem with it
>
>>>>> If implementing a custom
>>>>> resource type means to implement all these mentioned components,
>>>>> it means to virtually implement a document management system for
>>>>> each advanced and complex resource type.
>>>>
>>>>
>>>>
>>>>
>>>> yes, but what is the alternative?
>>>
>>>
>>>
>>> IMO the reference concept is sufficient to fulfil the requirements
>>> mentioned until now.
>>
>>
>>
>> maybe it is, maybe it's not. My experience tells me that everytime one
>> thinks one has now covered all usecases, a new usecase pops up.
>>
>> Off Topic: for instance I think the 1-to-1 mapping of "lenya meta
>> files" is not
>> sufficient as it is today, because for instance the usecase of
>> dynamic URLs, e.g.
>> the timestamp, or proxy requests are not covered, but can only be
>> covered by
>> allowing more general patters after the 1-to-1 mapping.
>
>
> I don't quite understand this - could you please give an example?
right now every URL needs a Lenya meta file (1-to-1 mapping), e.g.
calendar.html is being mapped to calendar/index_en.xml.meta
but what if you have a proxy resource type for instance
proxy/** --> proxy.meta (???)
any you don't know what URLs are actually being available, then a
wildcard rule help or
if you have URLs like
time/45654645656.html (time/**) ---> millis.meta
...
>
>
>>>> And as said above I don't think that's a problem
>>>> because of the argument above. Also one can offer tools to simplify
>>>> the process, just as
>>>> for instance there are tools to create XML Schemas, etc.
>>>
>>>
>>>
>>> Well, IMO the major problem is that it is much harder to achieve
>>> stability and backwards compatibility when the API becomes more
>>> complex.
>>
>>
>>
>> as said, I don't think it's more complex, but less specific, whereas
>> in most problems maybe one specific implementation can be used.
>>
>> I understand the difficulty to abstractize, because it took me for
>> instance a long
>> time to understand how specific polynomials can form a vector space:
>>
>> http://en.wikipedia.org/wiki/Examples_of_vector_spaces
>> http://en.wikipedia.org/wiki/Vector_space
>>
>> but recognizing it in the end will solve a lot of problems very quickly.
>>
>> And I think recognizing the generic API and providing implementations
>> (as the by you mentioned reference implementation) will make things
>> very simple in the end.
>
>
> OK, let's see where this thread leads us ...
;-)
Michi
>
> -- Andreas
>
>
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
+41 44 272 91 61
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [Proposal] Moving components configuration to the resource type
API
Posted by Andreas Hartmann <an...@apache.org>.
Michael Wechner wrote:
[...]
>> If you use two Lenya documents, and use the (not yet existing)
>> reference mechanism to link from the primary document to the
>> secondary document, the internal Copier, Revisioner, and Deleter
>> components will be able to handle this just by following the
>> references if this is desired.
>
>
> which I would consider a very helpful implementation, but it shouldn't
> be confused with the API.
What do you mean with "confused with the API"?
It would be part of the API:
Document.addReference(Document, int referenceType)
Document.removeReference(Document)
Document.getReferences()
...
[...]
>> The more implementation options you want to give to the integrator,
>> the more difficult it will be to design a comprehensible and
>> maintainable framework.
>
> it's not that complex. We already have everything, but we need to
> abstractize it just as JCR is an API working on nodes and properties
> instead working on directories and files ;-)
Yes - the Lenya API should support working on documents.
But a custom copier, deleter, ... would have to operate
"behind the scenes".
>> Another issue is the communication between components. You have
>> to find a "least common denominator" to design interfaces. If
>> you want to allow polymorphism for a family of components which
>> operate on the same data, you're likely to end up with the
>> MagicContainer antipattern (see the Creator interface). And IMO
>> a ParameterObject should not be used fo inter-component
>> communication.
>
> can you give an example here as well?
Imagine you have a JCR-based repository implementation.
Then your Copier interface might look like this:
Copier.copy(Document src, Document dest, javax.jcr.Session session)
In a RDBMS-based implementation, it might look like this:
Copier.copy(Document src, Document dest, DBConnection conn)
In a file system based implementation, it might look like this:
Copier.copy(Document src, Document dest, File contentDir)
And so on.
But if you want to export the Copier interface in the API,
you have to provide a generic parameter passing mechanism,
e.g. with a ParameterObject:
Copier.copy(Documetn src, Document dest, RepoInformation info)
That's not elegant at all.
BTW, this brings up another problem if we allow multiple repo
implementations:
If you want to allow custom Copiers, Revisioners etc. for different
resource types, you end up with (resource types) x (repo impls)
implementations, e.g. a
XhtmlJcrCopier
XhtmlFilesystemCopier
...
OdtJcrCopier
OdtFilesystemCopier
...
>>>> If implementing a custom
>>>> resource type means to implement all these mentioned components,
>>>> it means to virtually implement a document management system for
>>>> each advanced and complex resource type.
>>>
>>>
>>>
>>> yes, but what is the alternative?
>>
>>
>> IMO the reference concept is sufficient to fulfil the requirements
>> mentioned until now.
>
>
> maybe it is, maybe it's not. My experience tells me that everytime one
> thinks one has now covered all usecases, a new usecase pops up.
>
> Off Topic: for instance I think the 1-to-1 mapping of "lenya meta files"
> is not
> sufficient as it is today, because for instance the usecase of dynamic
> URLs, e.g.
> the timestamp, or proxy requests are not covered, but can only be
> covered by
> allowing more general patters after the 1-to-1 mapping.
I don't quite understand this - could you please give an example?
>>> And as said above I don't think that's a problem
>>> because of the argument above. Also one can offer tools to simplify
>>> the process, just as
>>> for instance there are tools to create XML Schemas, etc.
>>
>>
>> Well, IMO the major problem is that it is much harder to achieve
>> stability and backwards compatibility when the API becomes more
>> complex.
>
>
> as said, I don't think it's more complex, but less specific, whereas
> in most problems maybe one specific implementation can be used.
>
> I understand the difficulty to abstractize, because it took me for
> instance a long
> time to understand how specific polynomials can form a vector space:
>
> http://en.wikipedia.org/wiki/Examples_of_vector_spaces
> http://en.wikipedia.org/wiki/Vector_space
>
> but recognizing it in the end will solve a lot of problems very quickly.
>
> And I think recognizing the generic API and providing implementations
> (as the by you mentioned reference implementation) will make things very
> simple in the end.
OK, let's see where this thread leads us ...
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
andreas.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org