[Dev] risks [was (db policy) transparent persistence]
chrism at zope.com
Wed Nov 27 20:00:27 PST 2002
FWIW, I think you need to work out the functional requirements of
Chandler at a high level and then see if you can map them to other
technologies. This should be done on an as-needed basis only after you
know what it is you want Chandler to fully do.
But breaking my own rule above, as far as Zope goes, from what I've been
reading so far, I'm not sure that there's much in the way of code that
Chandler can "steal" from Zope other than possibly ZODB.
One observation: your requirement to use ZODB from other languages may
be a bit troublesome, because at the core it really is just a bag of
Python objects and makes no attempt to be a generic OODB framework for
other languages. So you will end up needing to implement lots of
"bridge" machinery to access ZODB objects directly from other languages
or you will need to use some lowest-common-denominator RPC mechanism to
get at data in the ZODB.
On Wed, 2002-11-27 at 20: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.
> 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.
> 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.
> > 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.
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> Open Source Applications Foundation "Dev" mailing list
More information about the Dev