[ZODB-Dev] CMS on top of ZODB

[Chris McDonough]

Dieter,

I am curious whether you think there is an opportunity here to develop a
"standardized" XML-to-Zope-object serialization of large SGML/XML
documents.  ParsedXML doesn't really fit the bill, as it doesn't do
anything special to break nodes across database records.    XMLDocument
probably doesn't have enough features, and I don't even know whether it
works or not anymore.

I am also wondering whether you think you might be able to use the
application level version control system written by Brian Lloyd at
http://cvs.zope.org/Products/ZopeVersionControl/  instead of hacking
ZODB to do this.



On Sun, 2003-02-09 at 03:36, Dieter Maurer wrote:
> The company I am working for used S=F6rman-CMS (formerly POET-CMS),
> an SGML/XML Content Management System on top of the POET object database.
> Unfortunately, S=F6rman Germany went bankrupt and
> we do not trust the company that took over the CMS to fulfill our
> support requirements (as it took over only the software but no people
> involved with its development). Therefore, I am exploring the possibility
> to implement our core requirements on top of ZODB.
>=20
> Core requirements are:
>=20
>   *  management of many (in the order of hundreds of thousands) SGML/XML
>      documents, some of them in the order of several MB in size
>=20
>   *  documents are made up of components with versions (called
>      "history" in Zope/ZODB) which can be shared between
>      documents
>=20
>   *  highly concurrent use (about 200 concurrent active users with
>      write access; steadily increasing)
>=20
>   *  stress read access during production (of publications produced
>      out of the CMS)
>=20
>   *  X-Metal integration (on top of an intranet protocol).
>=20
>   *  High availability/replication
>=20
>=20
> I think I will be able to implement about 90 percent of these core
> requirements on top of ZODB in a matter of weeks.
>=20
> However, there are some tricky issues, I would like to discuss:
>=20
>   *  ZODB's optimistic concurrency control
>=20
>      It requires that the probability of conflicts is low (fullfilled
>      in our setup) and the effect of conflicts is not desastrous
>      (not fullfilled in our setup; checkins can take many minutes
>      and it were bad when they had to be retried due to conflicts).
>=20
>      If necessary (after having exhausted application specific conflict
>      resolution), I would implement (object) locks in the ZODB:
>=20
>        Read locks would do nothing except prevent to acquire a write lock
>        (by a different connection) and to write the object.
>=20
>        Write locks would prevent to acquire other locks on the object
>        and behave like a simulated write (with identical content)
>        with respect to cache control.
>=20
>=20
>   *  Versioning/History
>=20
>      ZODB's version/history support is almost identical to that implement=
ed
>      by S=F6rman-CMS. Its only drawback: it gives us only very limited
>      control over the versions.
>=20
>      I think, we could enhance the packing process to recognize
>      special objects (based on classname) to hold references
>      to older versions. We could then use a standard marking
>      garbage collection for packing: current versions and
>      versions referenced by (current) special objects are
>      in use; any version referenced by a version in use is in
>      use.
>=20
>      The "version referenced by a version" is a bit tricky, as
>      a version references another version only indirectly:
>      it directly references an object and it is associated with a time;
>      it references the object's version that was current at this time.
>=20
>      Of course, packing would become considerably more expensive...
>=20
>=20
> What do you think about the prospects of these extensions?
>=20
>=20
> I can make extensions to ZODB (with respect to programming skills
> and employment contract obligations) and donate them back to the core,
> when you are interested...
>=20
>=20
> Dieter
>=20
> _______________________________________________
> For more information about ZODB, see the ZODB Wiki:
> http://www.zope.org/Wikis/ZODB/
>=20
> ZODB-Dev mailing list  -  ZODB-Dev@zope.org
> http://mail.zope.org/mailman/listinfo/zodb-dev