other formats (Re: [Dev] 4Suite RDF and ZOD)
psnively at earthlink.net
Sun Nov 3 08:48:21 PST 2002
On Saturday, November 2, 2002, at 11:57 PM, David McCusker wrote:
> That's a nice diagram. I'm generally in favor of more layers, when
> each layer acts to protect code on both sides of the boundary from
> depending on each other overly much. The performance impact of extra
> layers is generally neglible as long as there are not many layers, and
> as long as copying doesn't happen heavily at each layer boundary.
As Eric says, hear, hear! Layering is good when properly architected
not to kill performance.
> I like the Storage Layer idea. Basically I'd like a spec for what the
> model needs to store, expressed as an interface a model could use for
> reading and writing whatever it likes to store persistently.
With this thought firmly in mind, has everyone read
<http://www.w3.org/TR/rdf-concepts>? This is an excellent summary
overview of RDF, with links to other normative documentation. It
clearly shows the directed-graph nature of the RDF data model, and
clearly distinguishes it from its XML serialization.
> Having more re-usable libraries for the open source world is cool.
> And the prospect of being able to easily replace the storage is quite
> useful, both for storage providers and for Chandler folks in testing.
> (Sometimes it's easier to isolate causes of bugs by replacing parts of
> a system with supposed equivalents to see whether bugs persist.)
To say nothing of being able to evolve to address
> If someone can get e4Graph working as Chandler's storage, or any other
> fully general storage mechanism, then that sounds like the design for
> persistence is on the right path. I'd guess having both a Python and a
> C level API for storage replacement would make sense. (I need to start
> learning about Python internals for C and C++ primitive wrappers.)
I've come to believe, sadly, that e4Graph won't scale adequately to
address some requirements that I've learned off-list. I don't know that
I can say more without explicit support from someone at OSAF. This
probably won't stop me from attempting to add Python wrappers to it and
make it available if only as a small-scale testbed utility (or, for
that matter, something that may still be quite useful in other, smaller
Re: Python C++ wrapping, see <http://cxx.sourceforge.net>,
<http://www.boost.org/libs/python/doc/index.html>. Given what I know of
your design preferences, let me suggest you examine SCXX first. At the
other end of the spectrum, perhaps not surprisingly, Boost Python seems
the most featureful.
> Oh, I'm sure they'd still meet the requirements based on satisfying the
> API and desired semantics. They might not have the same performance
> or same something else as alternatives.
Having spent a lot of time pushing e4Graph, let me add that I wholly
agree with David: without knowing more about requirements other than
API and semantics, I'm quite sure that a decent RDF API around ZODB
would be fine. And actually, I remain quite curious about RDF querying,
which remains undiscussed.
> --David McCusker
More information about the Dev