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

[David McCusker]

Michael R. Bernstein wrote:
> John Anderson has emphasized on this list that Chandler will be
> developed using a 'Model-View-Controller' methodology. This should make
> alternative storages feasible, at least.

Hi Michael.  The MVC approach usually emphasizes the way models don't
really know what or how many views are displaying model content.  As a
result the data model is not very concerned about how the UI works, since
views can behave as they like without disturbing a model's preconceptions,
since a model isn't supposed to have perconceptions about views.

Typically models notify watchers (listeners, dependents, subscribers, etc)
when model content changes so it can be rendered as a view likes.  The
relationship usually broadcasts model changes to objects watching a model
without understanding anything about message recipients, with the net
effect of removing any dependency on the views within a model.

However, views are dependent on models since they must ask for content in
whatever form a model is willing to use.  If the model API presents data
in the form of RDF mechanisms, then views must use RDF if there is no
parallel mechanism for asking the same questions of models.

Ideally, a model could expose access to model state without requiring a
specific technology for accessing the content, and that helps keep the
views from depending overly much on mechanisms the model uses internally.
MVC helps keep models from depending on views, but only thoughtful design
of model APIs will keep views from depending on model internals.

Coupling between models and views would be less if neither demanded the
other use a particular content representation standard.  However, if they
both use the same internals, it could be more efficient to directly
interact using some common technology mechanism.  Maybe the direct and
efficient approach could be negotiated through optional interfaces.

> I for one, would find such a discussion very valuable, even if it ended
> up reaffirming the choice of an RDF centered design. A similar
> discussion on XUL vs. wxWindows for the UI was very informative as to
> how wxWindows was chosen. My own strawman guesses about how RDF would be
> persisted in the ZODB resulted in Eikeon adding a ZODB storage backend
> to RDFLib. :-)

I find it too easy to fall into ridiculously abstract descriptions of
data relationships, but that's only useful when one wants to permit
big rearrangements in concrete representations.  When folks are committed
to a specific system like RDF, then it seems silly to talk about objects
being composed of attributes, and how these might be represented.

I'd hope RDF and ZODB never became unsuitable for representing the model.
I was just interested in opening up the game so other ways of encoding
things would work. It would also help define what was being accomplished
when RDF and ZODB were in fact used to encode the data.  I'll take a shot
at theorizing about model data soon since you'll value such discussion.

> It was not my impression that the end user is supposed to be aware of
> the storage details at all. On the contrary, the Vista prototype relies
> heavily on 'virtual' views that are divorced from the storage model.

Well, if Chandler is a platform of sorts, then it has both a user level
presentation and a developer level presentation, where developers see a
more technology centric view of what happens inside.

It would be cool if the developer level view of models did not promise a
particular storage model was used inside, since that would permit more
alternatives.  I haven't seen the APIs involved so I don't have much
idea whether it's an issue.

--David McCusker