other formats (Re: [Dev] 4Suite RDF and ZOD)

[Paul Snively]

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.
>
Hi, David!

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 
heretofore-unarticulated requirements.

> 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 
production contexts).

Re: Python C++ wrapping, see <http://cxx.sourceforge.net>, 
<http://starship.python.net/crew/gmcm/scxx.html>, and 
<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
>
Best regards,
Paul