I have an interesting issue which I don't think has been raised. But instead of solving the issue myself I thought I would share it with you guys/gals and see what you think.
I am currently working on a Zope MailIn product, which allows you to send emails directly in to Zope. Version 0.1 can be found at: http://www.zope.org/Members/NIP/ZMailIn
In version 0.2 I plan to have a ZMailIn python product which will handle the Zope side of things and behave a bit like a client. For example you could add a ZMailIn product instance in to Zope and configure it to receive all emails for bob@bobscompany.com and provide a method to execute upon mail arrival.
This is great and you could have n ZMailIn product instances throughout your Zope site and in any position.
When email arrives I need to find all the ZMailIn instances within the ZODB and hand the email to the correct one.
I have decided AGAINST searching the ZODB for instances of ZMailIn because that is just too scary, hideously inefficient and I don't want to go there. Instead I thought of keeping an up-to-date list of where all the current instances where held. My original idea was to get the ZMailIn product to write a file in to the /lib/python/Products/ZMailIn directory, which shouldn't cause any problems that I can see.
However, It had occurred to me that with the current growth of Zope it was going to become more popular that separate Zope instances of the same product may need to share some data.
So my question is this: What are peoples opinions on storing shared product data? Where should it be placed? Should this ability be added to Zope as a standard?
Thanks in advance. -Andy Dawkins (New Information Paradigms Ltd)
Andy Dawkins wrote:
So my question is this: What are peoples opinions on storing shared product data? Where should it be placed? Should this ability be added to Zope as a standard?
So, this would be the zope equivalent of the unix "/etc/" directory?
Perhaps you could have "etc (Product Settings)" as a subfolder of control panel.
-- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net
Andy Dawkins writes:
I have decided AGAINST searching the ZODB for instances of ZMailIn because that is just too scary, hideously inefficient and I don't want to go there. Instead I thought of keeping an up-to-date list of where all the current instances where held. My original idea was to get the ZMailIn product to write a file in to the /lib/python/Products/ZMailIn directory, which shouldn't cause any problems that I can see.
... snip ...
So my question is this: What are peoples opinions on storing shared product data? Where should it be placed? Should this ability be added to Zope as a standard?
Shared data should go in zope/var, or a subdirectory of that. Zope/lib should be considered read-only by running products unless explicitly changed by the user. As you have correctly pointed out, lots of machines share Zope installations for multiple servers.
A standard interface for Python code to get a private subdirectory of var might well be useful.
Dan wrote:
Shared data should go in zope/var, or a subdirectory of that. Zope/lib should be considered read-only by running products unless explicitly changed by the user. As you have correctly pointed out, lots of machines share Zope installations for multiple servers.
A standard interface for Python code to get a private subdirectory of var might well be useful.
Now we're talking, that sounds reasonable. Thanks for pointing out the zope/var vs Zope/lib, point taken. I'm about to code this bit now so for version 0.2 I'll put a text file in the zope/var directory.
The private subdirectory idea sounds great, but I think some people may prefer a ZODB solution due to backup's, accessibility and, dare I say it, ZEO.
Arrgghh, ZEO I didn't think about it until just then. Are there any ZEO issue's I need to be aware of?
OK - These are great suggestions and I am taking them all in, honest.
Cheers -Andy
Just my $0.02 worth...
If you can at all avoid it, I think you should find a way to store it in the ZODB. Maybe a Configuration product that would allow you to create arbitrary configuration information and still be able to access it without making filesystem calls. Think about DC's Zope on a CD demo. Not that you really need to do that sort of thing, but it's really not going to work if you have to write stuff to the filesystem.
Actually, an XML Docment somewhere at root level should give you the kind of flexibility you're looking for. Lot's of people are using XML files for conf these days (they're all jumping... don't you want to...)
That being said, I totally agree that if you need to store something in a file, put it in Zope/var. I, for one, have my Zope application code on partition along with other apps, and the data, like Data.fs on another. I typically don't expect the apps partition to grow very much, or very often, In fact, only when I install something. So it would be quite shocking to have that space filling unexpectedly.
But, as always, the choice is completely up to you.
Monty
>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<
On 6/30/00, 3:27:42 PM, Dan "L." Pierson dan@sol.control.com wrote regarding [Zope-dev] Product Data Storage:
Andy Dawkins writes:
I have decided AGAINST searching the ZODB for instances of ZMailIn
because
that is just too scary, hideously inefficient and I don't want to go
there.
Instead I thought of keeping an up-to-date list of where all the current instances where held. My original idea was to get the ZMailIn product
to
write a file in to the /lib/python/Products/ZMailIn directory, which shouldn't cause any problems that I can see.
... snip ...
So my question is this: What are peoples opinions on storing shared product data? Where should
it
be placed? Should this ability be added to Zope as a standard?
Shared data should go in zope/var, or a subdirectory of that. Zope/lib should be considered read-only by running products unless explicitly changed by the user. As you have correctly pointed out, lots of machines share Zope installations for multiple servers.
A standard interface for Python code to get a private subdirectory of var might well be useful.
Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
If you can at all avoid it, I think you should find a way to store it in the ZODB.
Ultimatley thats what I am aiming for
Maybe a Configuration product that would allow you to create arbitrary configuration information and still be able to access it without making filesystem calls. Think about DC's Zope on a CD demo. Not that you really need to do that sort of thing, but it's really not going to work if you have to write stuff to the filesystem.
A Configuration product isn't a bad idea, although it still leaves the question of where do you put it, in the root? in a configuration directory? in the Product folder?
Actually, an XML Docment somewhere at root level should give you the kind of flexibility you're looking for. Lot's of people are using XML files for conf these days (they're all jumping... don't you want to...)
I am not too keen on writing confurations or preferences documents on the root. My reasoning is that the root is not the correct place for that kind of thing, you don't see any linux confurations in / its all filed away nicely in respective folders.
That being said, I totally agree that if you need to store something in a file, put it in Zope/var. I, for one, have my Zope application code on partition along with other apps, and the data, like Data.fs on another. I typically don't expect the apps partition to grow very much, or very often, In fact, only when I install something. So it would be quite shocking to have that space filling unexpectedly.
This is how it is going to work for now. I have taken Dan Piersons advice for this one.
Thanks for your comments.
-Andy
-
Andy Dawkins -
Dan L. Pierson -
Monty Taylor -
Steve Alexander