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

Michael R. Bernstein webmaven at lvcm.com
Sun Nov 3 11:47:28 PST 2002


On Sat, 2002-11-02 at 23:30, David McCusker wrote:
> 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.
>
> [snip]
> 
> 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.

Ok, I see what you're saying here. My current understanding of
Chandler's design approach (based on judicious reading of tea leaves) is
that the model is intended to be modular. A Package defines an Item
class, which has attributes. I would guess that a view would need to
genericly register a query that defined the objects it wants to display
and a list of attributes that it's watching for, and probably get back a
set of nested dictionaries representing the objects and their
attributes.

For the local desktop application, no RDF is used to view the objects in
this way.

I am guessing that for sharing, the data is serialized by the View to
XML/RDF for transport over Jabber to remote copies of Chandler.

So, the modular part comes in when you want to describe relationships
between arbitrary objects in different Packages, such as saying 'Bob is
a member of X', where 'Bob' is a Contact Item, and 'X' is a Project
Item. Rather than store an attribute on either the Project or Contact
Item (defined in their respective Packages), Chandler stores the
assertion as a triple in the form 'subject, predicate, object'.

Thus, the Project X View can query the model for all Contact objects
that have the assertion 'member of X' (along with a list of fields), and
display them in the View.

> > 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.

Hmm. When you say 'concrete representation' do you mean physical 'as
opposed to logical' storage on the hard drive?

> > 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.

Well, none of us have either. But I expect that to change.

Cheers,

Michael bernstein.




More information about the Dev mailing list