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

[Eric Gerlach]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

At 10:13 PM 02/11/02 -0800, 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.

I'd just like to point out that the MVC pattern doesn't necessarily
make multiple storage technologies simple.  It does make multiple UIs
simple though (thus answering the calls of those who are saying to
use PyQt and such).  Take a look at the links I provided in my second
email on the subject:
http://lists.osafoundation.org/pipermail/dev/2002-October/000049.html

Making alternative storage methods possible needs to be something
that happens within the Model of the MVC pattern.  To allow for
multiple storage technologies, one has to make another layer (which I
would recommend, if only so that the storage layer could be used in
other apps.)

A lovely ASCII art rendition of my thoughts (may look wrong if you
don't use a mono-spaced font):

        +---->User----+
        |             |
        |             v
      View       Controller
        ^             |
        |             |
+------|--+-----+----|--------+
|      |  |Model|    |        |
|      |  +-----+    |        |
|      |             v        |
|     Manipulation Layer      |
|        ^         |          |
|        |         v          |
|       Storage Layer         |
|        ^         |          |
+--------|---------|----------+
          |         |
          +- Data <-+


In this diagram, as per a normal MVC-based approach, the user is
presented a view (a form), and sends input into a controller (where
the changes go after pressing the OK button).  However, I've broken
down the Model into a Manipulation Layer, which makes sense of the
data, and a Storage Layer, which handles the grunt work of storing
and retrieving data.

There are two benefits to this design.  One, as I mentioned above,
the Storage Layer can be separated into its own library and used in
other applications -- this would be a huge boost to the Open Source
world.  Second, now the Storage Layer is easily replacable if a
faster/more secure/more reliable technology comes along, so long as
it supports the same semantics -- this is what allows multiple
storage technologies.  (There was a suggestion of e4Graph some time
ago on the design list, for example)

So what really has to be done is to determine the format of data that
Chandler needs to store while not constraining it to particular
technologies and implementations.  Once that data model is reasonably
well defined, RDF and ZODB should be re-evaluated to see if they
still meet the requirements.  I see no reason they wouldn't, they're
both great technologies... but you never know.

Cheers,

Eric

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (MingW32) - WinPT 0.5.13

iD8DBQE9xMP+nuiuBLkZNokRAsu2AKCL/ddhJuNY1suwWlaSZnOymEMulACdHVbC
/FylVw9iZuavbbt1/I5Z0GY=
=+Kh0
-----END PGP SIGNATURE-----