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, and I've been looking at the issues. It would be nice to sell the user x amount of space, then logically partition my drive so that each user gets that x. However, this would require me giving each of them a data.fs file.
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? And it's the python interpreter that has the lock problem, so I'd need 20 pythons, too, nyet? 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. I have to have all sorts of strange rewrite rules (same as multiple zopes, I guess) I have to be the one installing Products. 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. -- Ethan "mindlace" Fremen you cannot abdicate responsibility for your ideology.