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.