"Marcelo F. Ochoa" wrote:
>
> Per Kreipke wrote:
>
> >>
> >
> >I agree with Gianugo that the CMS should hide the store:
> >
> >user agent <- publishing <- CMS <- edit agent
> > |
> > store
> >
> >But I would definitely expect to allow this for performance or simplicity:
> >
> >user agent <- publishing <- CMS <- edit agent
> > ^ |
> > |------- store
> >
> >Cocoon shouldn't require a CMS but should use one if it has it [you say so
> >yourself later].
> >
> DB Prism CMS uses a different approach to speed up the response time,
> and do not requires Cocoon modifications:
> Here the flow:
> user agent <-- Oracle Web Cache <-- publishing <-- DB Prism CMS
> <-- upload utility <-- Edit Agent
> ^
> | (document-v10 compliant)
>
> |---------------------------------------store OO upload
> through XSL transformations
>
> This flows guarantee around 10 second for the first time access to a
> CMS page, and 4ms aprox. for the other access.
> When a user update a document into the CMS repository a trigger
> instaled into PAGES table send an XML post message to Oracle Web Cache
> to signal that this pages was modified and is no longer valid, in the
> next request Oracle Web Cache load a new version from the CMS repository.
> Obviously this CMS includes search engine, versioning, images stored
> into the repository as SVG format inside the Apache document-v10
> compliant documents, and so on.
> Best regards, Marcelo.
well, I don't see how we could do that over a native XML DB if my XQL
query spans document borders. If I store documents and I retrieve
documents the above is the right method to follow, but given the power
doing infra-document searching, the caching metodology will have to be
*much* more sofisticated than this.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<stefano@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
|