[Dev] risks [was (db policy) transparent persistence]

THoffman at indtech.wa.gov.au THoffman at indtech.wa.gov.au
Wed Nov 27 18:29:27 PST 2002

Hi David

On Thu, 2002-11-28 at 09:55, David McCusker wrote:
> THoffman at indtech.wa.gov.au wrote:
> > I know this will come up often but you guys should have a
> > look at Zope some time (yeah I am sounding like a broken record)
> I don't know who will have time to look at Zope.  Do we have any list
> members who care to summarize what Zope is in 50 words or less?  I have
> some idea, but I'm sure I can't summarize it.  The important thing is
> that Zope is lots of things, and we can't tackle all of it and also
> make headway in our own app frameworks.

Oh I agree with you totally on this. 

I am seeing many discussions of how to solve certain things, or
potential approaches to problems, and in many cases these are things
that Zope already does. Also I often see various people trying to
explain concepts on the list, which I have seen as concrete working
examples in Zope.

This does not mean that Chandler should use Zope by any means, just that
there is another python project out there that already uses ZODB, that
does many similiar things. From the point of view of expediency it may
be simple to grab some of these tools/methods/designs whatever, see them
work, get some ideas and maybe use it for real or turf it. The advantage
is you can interact with a working python system now. 

I will try and summarize some specific features that Zope uses that seem
to overlap with Chandlers  aims. 
> I'd expect there to be a huge overlap in general technologies involved
> in both Zope and Chandler, so attempting to use Zope to move Chandler
> along would amount to training all the Chandler engineers in the Zope
> perspective, and the cost of some months, after which they will no
> longer have the independent will to design Chandler from scratch.

Yes this could be a definite downside. 

But given you aren't likely to rebuild ZODB, RDF, Jabber and python for
that matter, but you plan to use stable working tools that already exist
is there, is there really that much danger of Zope subsumming Chandler. 
Zope is a big system (well not really that big) and trying to take it
all would be a mistake. 

It is already going through a ground up rewrite, learning from it's
previous incarnations. It is being further componentised in Zope 3. One
of it's aims is to be able to use Python code/libraries that are not
Zope base more easily (ie less Zopificaton required). BUt also I think
many of it's components may well be better at standing alone as well.

Maybe it's more of a raid the Zope cupboard for some ideas. (Thats the
cupboard where ZODB and ZEO originally came from)

I think as long as you can look, maybe learn, and be prepared to
discard, then should be safe.

Maybe a few of the other people on this list who are also involved with
Zope can give specific examples (ie code, design etc) of how Zope
specifically solves a problem, the rest of the Chandler community can
look at it as just another idea (that just happens to work elsewhere
already that they can touch and feel)

> Is that a fair assessment of what would happen?  I'm perfectly happy
> to understand a better situation than this when we can both benefit
> by sharing direction.
> > It can and does have code in both the Filesystem and in the ZODB.
> A database should be general purpose enough that it can store anything.
> At the moment I don't know what code Chandler would store in a db.
> We'd certainly need either capabilities or ACLs (access control lists)
> to prevent trojan code from being installed, if this could happen as
> the result of processing content, and not by Chandler choice alone.
> This reminds me of a brief topic in a conversation with Andy Hertzfeld,
> where we entertained the idea of adding capabilities to Python (and I
> suggested we ask Paul Snively what he thought of that, since it's a topic
> I'd expect to be dear to his heart :-).  It capabilities are not built
> in a the most primitive level, I don't suppose it's easy to add them
> higher up and actually have them be secure.

That I can't comment on. 

> > The code in the ZODB in zope is typically scripts run in a restricted
> > environment, so that TTW development is supported. This code
> > cannot open files, sockets etc...
> > 
> > Privelidged/Unrestricted code lives in the filesystem.
> > 
> > The two work well together, and I don't believe has caused many 
> > security issues
> We probably don't have time to come up with a whiz bang security model
> that partitions the world into different trust levels, at least not
> in the first cut, unless someone can start presenting a story about how
> this works that sounds clear to the rest of us.
> > Zope does have a sophisticated ACL model
> I hate to say this, but sophisticated suggests complex with a learning
> curve that helps prevent adoption by folks who want a simple system.

To be honest maybe I misused the term sophisticated. Nah actually it is
sophisticated, but I don't believe it is complex. However how it would
be usefull for Chandler in what on the face of it appears to be a single
user environment is another question altogether.

See ya


> David
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> Open Source Applications Foundation "Dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/dev

DISCLAIMER: This email, including any attachments, is intended only for use
by the addressee(s) and may contain confidential and/or personal information
and may also be the subject of legal privilege. Any personal information
contained in this email is not to be used or disclosed for any purpose other
than the purpose for which you have received it. If you are not the intended
recipient, you must not disclose or use the information contained in it. In
this case, please let me know by return email, delete the message
permanently from your system and destroy any copies. Emails and their
attachments may be interfered with, may contain computer viruses or other
defects and may not be successfully replicated on other systems. All
attachments are opened at the recipient's risk.

More information about the Dev mailing list