Re: [Zope-dev] Product Data Storage
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 ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] Product Data Storage
You should look into using ZCatalog for this purpose. -josh zeidner 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 [EMAIL PROTECTED] 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) ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 ) Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
RE: [Zope-dev] Product Data Storage
You should look into using ZCatalog for this purpose. OK - that is a solution that could solve my particular issue, but where would you put it? Would you put it in the Product folder, or in some common place in the ZODB. How would you create it originally? In the products __init__.py or by some kind of DTML method. Also would the ZCatalog be appropriate for storing general information to be shared between instances, Maybe some global configuration options. I am looking for a generalised method of storing Class Level Variables. Maybe properties within the Product folder. But above all I am looking for a method of doing this that the Zope community agrees as being efficient and recognises as being _the_ solution to the problem. I want to avoid a 'hack' solution if possible. -Andy Dawkins (New Information Paradigms Ltd) ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
[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 - [EMAIL PROTECTED] 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 )
RE: [Zope-dev] Product Data Storage
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 ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] Product Data Storage
Loren Stafford wrote: In that case we decided to put the Schedule in the root folder. There is no more global data than the catalog itself, but if there were it could be stored in the catalog folder, since catalogs are folderish. Hmm, this is messy. Could the Catalog not be stored in your case in: /Control Panel/Products/ZScheduler and in Andy's case in: /Control Panel/Products/ZMailIn ? I like your point about ZCatalog's being folderish though ;-) ZScheduler's __init__.py method creates this global data structure if and only if it doesn't already exist. Because ZScheduler creates it, it can assign the appropriate permissions and methods to manage the global structure any way it wants. This sounds like what you want to do, Andy... cheers, Chris ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
RE: [Zope-dev] Product Data Storage
I haven't thought much about this; I just followed mj's original design. Maybe there was some reason for this decision. Any comment Martijn? -- Loren Loren Stafford wrote: In that case we decided to put the Schedule in the root folder. There is no more global data than the catalog itself, but if there were it could be stored in the catalog folder, since catalogs are folderish. Hmm, this is messy. Could the Catalog not be stored in your case in: /Control Panel/Products/ZScheduler and in Andy's case in: /Control Panel/Products/ZMailIn ? ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] FWIW, ZCVSMixin now at 0.1.1... and rising. ;-)
Steve Spicklemire wrote: I don't know if anyone out there is actually trying to *use* my ZCVSMixin/ZCVS Folder stuff, but if you are you certainly want to get the latest release, ZCVSMixin-0.1.1.tgz from the zope.org site: http://www.zope.org/Members/sspickle/ZCVSMixin Hi, Steve. This work looks very interesting. I decided to try it out and noticed it was not possible to manage a product folder with ZCVSMixin, so I started hacking up your product. (Images that resemble a horror movie come to mind.) :-) I've attached my changes in a private e-mail so as to not flood the list. Basically I made it possible to override the behavior of ZCVSMixin so that it can manage a folder other than itself. Then I created a new class derived from ZCVSMixin which is a "CVS" Folder. That way, it's possible to manage any objects in the ZODB, regardless of whether CVS had been considered in the structure. I put some screenshots up there so you can see what it looks like at: http://www.zope.org/Members/sspickle It looks good, but the interface could be a lot cleaner. I envision a table with three distinct column groups: the ZODB version, the FS version, and the repository (with details). When the ZODB and FS are in sync, a small black equal sign will appear between them (preferrably a graphic to make it more visible.) When the FS and repository are in sync, there will be a small equal sign between them also. When something is not in sync, a green arrow pointing in the direction the file needs to go will replace the equal sign. The buttons below would be placed in such a way to make their function obvious. In fact, the submit buttons could be images containing the arrow icon. Thus the interface would be simple and obvious. I've also found it useful for managing Python products and other software through the web! I have had a couple of minor 'breakthrough's that *seem* cool, but I might just be fooling myself. If an object is not folderish I guess that it's 'simple' so I export it as XML with the following code: (snip) This looks good, Steve. If objects are 'folderish' or 'complex' (and the user is permitted to dictate this when objects are added to CVS), they are exported as 'zexp' files and cvs adds them as 'binary'. I was having trouble with certain kinds of object's xml representation. I decided that this was really an xml implementation problem, since I couldn't reliably export these as xml through the normal Zope export mechanism either. Anyway.. let me know what you think if you are using this stuff! I think we need to look into performing complete CVS checkouts which create entire folder hierarchies. Finally I'm aware that there are also security issues with the way this works now. I need to look at all the things a user might need to do and eliminate some of the 'type in' arguments that are in the product now. These arguments wind up on 'os.system' calls, and could be abused by a ill-meaning user (with access to the CVS Admin page!) Any thoughts there? Imagine this possibility: Zope would start what I'll tentatively call an "execution proxy" server at startup. When a user want to access CVS through Zope, they would be required to start a background "execution client" which makes a connection to Zope's execution proxy server. When the user accesses a CVS function in Zope, Zope would look at the list of connected execution clients and ask the appropriate execution client to access the file system and execute cvs commands based on that user's system privileges. Advantages: - Unless a given user is running the execution client, the possibility of intruders gaining access to that user's files is not increased. - Nothing has to run with root privileges. - The execution proxy could run on a privileged port, making it impossible for intruders to trick users into using a counterfeit execution proxy (unless, of course, the intruder already has root privileges.) - No need for administrators to fiddle with filesystem permissions. Disadvantages: - If Zope is compromised while execution clients are connected, the intruder may be able to execute commands through the execution clients. To reduce the impact, we can reduce the commands allowed to be executed. Note, however, that this problem is very likely inherent in CVS access through the web. Even the current implementation suffers from this problem. - Users will have to manually start their execution clients, which will stop automatically when they log out. This is actually designed to be an advantage in terms of security. On the other hand, it would be possible to write an execution client that runs as root and automatically spawns child clients for each user. That could be dangerous, though. It should be relatively easy to write all this IMHO. Shane ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross
Re: [Zope-dev] EMarket and 2.2.0b3
On Thu, 29 Jun 2000, Steve Spicklemire wrote: I'm sure a lot of this is because EMarket was a 1.x product that has seen relatively little change, in basic structure, since. I'm working It doesn't look that way, actually. on some patched to allow (1) ZClasses to act as MarketItems and Shoppers and (2) ZPatterns integration so that most objects can be optionally stored in RDBM or ZODB. .. I'll go ahead and checkin my ZClass stuff. I'm not running 2.2x much, since I'm This would be really great, thanks. really busy on other development... but I can at least see if the product installs! ;-) I figured out a way to fix the problem I was seeing, but I don't really understand why it caused the problem, though it does not seem unreasonable that it did (which is why I thought to experiment in this area of the code). MarketItem.py has the following code snippet near the beginning of the class definition: for item in OFS.Folder.Folder.manage_options: if item['label'] == 'Contents': manage_options.append(copy(item)) # be sure to muck with a *copy* manage_options[-1]['action'] = 'manage_contents' else: manage_options.append(item) Changing the last line to manage_options.append(copy(item)) makes the management interface behave normally with the product installed. It does not seem unreasonable to me to not make copies of things not being changed: why clutter up memory with copies? But clearly there are unexpected interactions later because of this, interactions that produce obvious strange behavior in 2.2.0 but seem to work fine in 2.1.x. I don't know if this has any security implications someone from DC should look at, but it's probably worth a note in the product author's security guide. I also have no idea whether or not the similar eTailor problem has a similar cause and solution. --RDM ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] FWIW, ZCVSMixin now at 0.1.1... and rising. ;-)
Steve and Shane, We've been positively *dying* to have cvs or cvs-like functionality. It's one of those things where we left the unix-everything-is-a-file-idiom and went, "Oh, um, heh, now what?" =) We have been making do with Version objects instead, which are far more rcs-like (exclusive locking, no merging) and not really good when we want to give 2 different people 2 different medium-to-long term projects for adding things to the site. Imagine, one adds something to / and / gets version-locked now, so the other person can't even add things to / anymore. Anyways, enough of that. Point being, we want our site coders to be able to do a sandbox (much like Version essentially provides, if possible, ie transparent rather than explicitly located somewhere else) where they can develop stuff and the ability to only check certain things in, and the ability to do merges, etc. If we couldn't do the development transparently on the production server, and we had to have developers running zope on their workstations and pull from the cvs repository there, that'd be alright too though I guess. How much of this is provided for now or planned on being provided for by this product? And, what can we do to help? I don't know that we have any bodies we can sick on this, but I'd love to get together with you guys and get some of the things that need to be done up on Cosource so that organizations interested in having this can throw money at it, and so that people (you guys included) who might have trouble finding the time to work on it can have a little incentive. =) jim -- Jim Hebert http://www.cosource.com/ [EMAIL PROTECTED] The cooperative market for open source software "Well actually I was considering opening a market in flying pigs. Mostly because it would be more practical" -- Alan Cox ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] EMarket and 2.2.0b3
On Fri, 30 Jun 2000, R. David Murray wrote: manage_options.append(copy(item)) makes the management interface behave normally with the product installed. Darn, I should have done more testing. I only fixed the prompt for permissions problem. manage_workspace still goes to the import/export screen...back to the testing. --RDM ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] EMarket and 2.2.0b3
On Fri, 30 Jun 2000, R. David Murray wrote: Darn, I should have done more testing. I only fixed the prompt for permissions problem. manage_workspace still goes to the import/export screen...back to the testing. Arg, it's worse than I thought. My original test was broken. I haven't found the problem at all. So please ignore all my recent posts about this and I'll crawl back under my rock and do some more careful testing. --RDM ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
