[Zope-dev] Re: Zope ISP'ing (was ZODB DA)

[Jim Fulton]

Ethan Fremen wrote:
> 
> Jim Fulton wrote:
> 
> > So there are two issues.
> >
> > 1. Concern over the approach of using a single file for the entire
> >    database. [...]
> >
> > 2. Separating data into multiple databases for organizational reasons
> >    and combining the multiple databases into a single logical object
> >    space. [...]
> 
> I'm interested in issues 1. and 2.
> 
> I'm intending to become a zope ISP here in the very short future,

Yee ha. :)

> and I've been looking at the issues.  It would be nice to sell the user x amount of space,

Yes

> then logically partition my drive so that

I assume that this is just a means to an end:

> each user gets that x.

So you want to be able to control how much space a
customer gets. That's the bottom line, right?

> However, this would require me giving each of them a data.fs file.

Not necessarily.  A better model, IMO, is to implement
a storage with an accounting model.  Extra meta-data was added to 
ZODB transactions to support this sort of thing.  For example, 
suppose each user had an account number. When a transaction is committed, 
the storage updates the space used by the account.  It can implement quota's
failing to commit transactions if the quota is exceeded. Other models 
are possible too, like charging for usage wo setting a quota.

Finally, you can make the quota orthoganal to location in 
the object system, so you don't have to limit a customer to 
one location and you can account for things like catalog space.

This sort of scheme could be achieved with relatively minor extensions
to user databases and storages. For example you could problably
use an accounting storage that wrapped another storage (much
like DemoStorage or Ty Sarna's CompressedStorage do).

> 
> > I think that there are already XML-RPC methods of some sort. Wouldn't
> > this, and multiple Zopes give you what you want?
> 
> I was thinking about doing this.  How much overhead do I take for allowing, say, 
> 20 instantiations of zope on the same machine? 

It depends on what their doing and what kind of machine.
Each will probably require a few megs to idle.

> And it's the python interpreter that has the lock problem,

What lock problem?  

> so I'd need 20 pythons, too, nyet?

You'd have two Python processes for each Zope
(or 1, if you disabled the process manager, or
extended the process manager to manage multiple
processes.)

Actually, come to think of it, it is probably
feasible to hack ZServer to serve multiple
object spaces in the same process.
 
> as to the "one zope, one data.fs" approach:
> I have to have some fs directory and ZFolder size comparator, to see that they're not using more than their alloted space.

Right, see my suggestion above.

> I have to have all sorts of strange rewrite rules (same as multiple zopes, I guess)

The forthcoming site objects will take care of the Zope
side of this, as will Evan Simpson's site objects.

> I have to be the one installing Products.

Right, and you may want to limit use of external methods.
 
> if I could have several data.fs files 
> (and _zero_ linkages amongst data.fs'es, they should behave like different zopes),
> then I could eliminate all the problems except the rewrite rules for apache.

and except for the need to control products and external methods.

Really, all you are gaining with multiple fs files
(in this context) is the ability to set quotas. I think there
is a better way to do this, however.

Jim


--
Jim Fulton           mailto:jim@digicool.com   Python Powered!        
Technical Director   (888) 344-4332            http://www.python.org  
Digital Creations    http://www.digicool.com   http://www.zope.org    

Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email
address may not be added to any commercial mail list with out my
permission.  Violation of my privacy with advertising or SPAM will
result in a suit for a MINIMUM of $500 damages/incident, $1500 for
repeats.