- Zope-Dev - Zope lists

Re: [Zope-dev] Re: ZCatalog and Unique IDs
by Tres Seaver 31 May '00

31 May '00

Chris Withers <chrisw(a)nipltd.com> > > Evan Simpson wrote: > > There are generally two ways (at least) to think about "object > > identifiers". You can think of them as unique labels for > > specific objects, without regard for location ("Jim Fulton") > > Me too... > > > or as addresses or slots in which objects can be > > found ("the CTO"). > > who's the CTO? Jim is. > > > In this case, an advantage to using the address stance > > [snip path/catalog stuff] > > > use paths instead of object monikers. > > Why not do both? > > Have an POID (CORBA style) to actually identify an object and then use > paths of POIDS to identify stuff in a cotnext *when you need to*... > > comments? CORBA's Interoperable Object References come in two flavors: * "transient" references are valid only for the lifetime of the server (actually the POA) which creates them; in this respect, they are like the actual Python object references of an activated object in Zope. * "persistent" references are effectively required to be immortal: it is _mandated_ that one be able to stringify the IOR, copy it to a piece of paper, put the paper in a bottle, and cast it on the waves; whoever opens the bottle should be able to transcribe the IOR, reify the reference from the string, and communicate with the object (which may be an entirely new "incarnation" created just for this request). A general-purpose, persistable reference in Zope pretty much has to be represented as an absolute containment path -- no other mechanism I can think of will both survive a restart of Zope and deal with objects which may live in another storage. In CORBA terms, the "object id" part of the persistent reference would be the containment path (the other bits of a CORBA IOR are the hostname/IP address and port number of its server, or equivalent endpoint data for other transports). CORBA offers several interesting strategies for dealing with persistent IORs, and binding them to the "servant" objects which actually carry out the requests sent to the IOR: ServantActivator -- much like the ZODB, the SA keeps a list of currently active servants, and the IORs to which they are bound. When processing a request, the SA finds or activates ("incarnates") the proper object/servant and delegates to it. This pattern is usually used with the Evictor pattern, which deactivates ("etherializes" in CORBA terms) objects using a LRU (or other) policy when things get too crowded. ServantLocator -- keeps a pool of idle servants, binding them as needed to the IORs of incoming requests, and unbinding them according to a timeout or other policy. DefaultServant -- all requests are delegated to a single servant, who uses the object key to determine whom it impersonates. Tres. -- ========================================================= Tres Seaver tseaver(a)digicool.com Digital Creations "Zope Dealers" http://www.zope.org

2 2

Re: [Zope-dev] New Help System in 2.2
by Jason Spisak 31 May '00

31 May '00

Stephan Richter writes: > At 12:02 AM 5/31/00 +0000, Jason Spisak wrote: > > >Furthermore, we will include a new DTML reference soon. Do > > > you know about anything else, that should be included? > > > >Well if you really want to make it hot, the examples that are in there can > >keep coming. Web links might not be out of order either. The only problem > >is that there is no difinitive Zope online docs to link to, to get the most > >recent info. But when there is, it would be nice to include. > > The next task after the 2.2 release is that we will look through the > tutorial and see what it does not cover and then add the missing examples > in tutorial form. :) > Off-site links are okay, but what happens, if I sit in the plane and I need > that piece. Amos leans also towards external links I think, but I would > rather keep it in the distribution; it is only a couple thousand bytes more > and will not increase the distro size too much. > > A fact is, that most of the Zope Online Help should be the most up-to-date, > meaning that we try to encourage developers to update and patch the help > system as they update the code. Personally, I see that same thing might happen that happened to Zope. They'll want to get the product out badly, and since the help system is separate, they'll put it off. > Our goal is basically to initialize a good, > well organized Zope help system, which content is maintained by the > developers, read community. > I think this is terrific shot at offering everyone a chance to "get it". > BTW, if you find any mistakes or want to make additions to the help texts, > please send them to me. I hope I will be able to upload a complete revision > of *all* the help screens by the end of the week. I have only 80 documents > to go. :) Excellent. I am reading it. I founfa few "not found"'s but that stuff probably just not loaded yet. Jason Spisak CIO HireTechs.com 6151 West Century Boulevard Suite 900 Los Angeles, CA 90045 P. 310.665.3444 F. 310.665.3544 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.

2 1

ZDOM alpha release 2
by Chimezie Thomas-Ogbuji 30 May '00

30 May '00

See release notes for changes (installation process simplified w/ release of 4DOM/4XSLT/4XPATH): -- Chimezie Thomas-Ogbuji Consultant Fourthought Inc. (303) 583 9900 ext 104 cogbuji(a)fourthought.com ZDOM is the result of a collaborative venture by Digital Creations and Fourthought Inc. to integrate the W3C Document Object Model interface with Zope, allowing effortless and familiar traversal of a Zope heirarchy. The current alpha release is based on Fourthought's 4DOM , which is one component of Fourthought's 4Suite. Fourthought provides custom technological solutions based on open technologies. 4Suite is a powerful set of Python tools developed by Fourthought for Web-based applications in areas such as Intranets, E-Commerce and knowledge-management. Elements of 4Suite have been adopted as core XML technologies in Zope and in the Python XML distribution The necessary files (which are all available on our ftp server: ftp.fourthought.com) are ftp://ftp.fourthought.com/pub/mirrors/python4linux/redhat/i386/python-xml-n… (Py-XML w/out DOM) ftp://ftp.fourthought.com/pub/mirrors/python4linux/redhat/i386/4DOM-0.10.0-… (4DOM core) ftp://ftp.fourthought.com/pub/4Zope/ZDOM-dist.tgz (ZDOM) ftp://ftp.fourthought.com/pub/4Zope/Zope-ZDOM-Patch (patch file for Zope 2.1.6) OR http://www.zope.org/Members/anthony/patches/4ZDOM-vs-CVS-0512.patch (patch file for CVS/alpha 2.2 Zope) Documentation: ftp://ftp.fourthought.com/pub/4Zope/INSTALL.txt (the installation instructions) ftp://ftp.fourthought.com/pub/4Zope/Readme.txt (short description of ZDOM) ftp://ftp.fourthought.com/pub/4Zope/Release.txt (release notes) links: Fourthought: http://fourthought.com 4Suite: http://fourthought.com/4Suite/ DOM 2 Spec: http://www.w3.org/TR/2000/CR-DOM-Level-2-20000307/ Zope http://www.zope.org contact: consultants(a)fourthought.com Installing ZDOM --------------- This document describes installing ZDOM on Unix. Important Notes ZDOM REQUIRES ZOPE AND PYTHON 1.5.2! Depending on which Zope version you wish to add ZDOM to, there are two patches to download 1) ftp://fourthought.com/pub/4Zope/Zope-ZDOM-Patch (patches Zope 2.1.6) 2) http://www.zope.org/Members/anthony/patches/4ZDOM-vs-CVS-0512.patch (Anthony Baxter's patch which works on the CVS source tree as of 5/16) ftp://ftp.fourthought.com/pub/mirrors/python4linux/redhat/i386/4DOM-0.10.0-… (4DOM core) ftp://ftp.fourthought.com/pub/4Zope/ZDOM-dist.tgz (ZDOM) ftp://ftp.fourthought.com/pub/4Zope/Zope-ZDOM-Patch (patch file for Zope 2.1.6) OR http://www.zope.org/Members/anthony/patches/4ZDOM-vs-CVS-0512.patch (patch file for CVS/alpha 2.2 Zope) Installing First download these files from our FTP server: /pub/mirrors/python4linux/redhat/i386/python-xml-nodom-0.5.4-1.i386.rpm /pub/mirrors/python4linux/redhat/i386/4DOM-0.10.0-1.noarch.rpm /pub/4Zope/ZDOM-dist.tgz /pub/4Zope/Zope-ZDOM-Patch OR http://www.zope.org/Members/anthony/patches/4ZDOM-vs-CVS-0512.patch Install the rpms and decompress ZDOM-dist.tgz somewherer in your PYTHONPATH Install and build Zope 2.1.6 if not already done. This is required for the components to work. The following will install the patches to Zope objects to allow manipulation of Zope object via the DOM interface: (the Zope2.1.6 patch assumes that the Zope src files reside in a 'Zope' directory so a symbolic link is necessary) ln -s [Zope install dir] Zope cd (parent directory of Zope install dir) -- if necessary patch -p0 < (location of dowloaded files)/Zope-ZDOM-Patch OR 4ZDOM-vs-CVS-0512.patch Then add '(zope install dir)/lib/python' to your PYTHONPATH. RELEASE NOTES ------------- 5/30/00 changed setAttributeNodeNS to check for aq_base and set to None if it doesn't exist (since _setProperty expects aquisition to be set up -- but might not be necessarily so since an element can be created and attributes can be added WITHOUT it having a parent yet) redirected computed attributes to instance methods so DOM interfaces can be overode added check for aq_base in setAttributeNodeNS (sets to None if it doesnt exist) 5/10/00 ZDOM alpha supports to complete DOM Level 2 Specification (http://www.w3.org/TR/DOM-Level-2/) ZDOM maps the DOM interface to Zope, like so: childNodes -> objectValues() mappable subset of DOM 2 Interface -> attributes -> propdict() parentNode -> self.aq_parent Default implmentation of both objectValues() and propdict() are provided on SImpleItem.Item for Zope Objects that do not implement these interfaces. All Zope objects support the DOM Level 2 spec through the inheritence of SimpleItem.Item from Element. All objects (except as noted below) created by the use of the DOM interface (i.e., NodeLists, NamedNodeMaps, childNodes for Attr) are transient. All Zope objects not defined in a namespace default to "http://www.zope.org/ZNames/NullNamespace" with the prefix of "zope". The cloneNode() interface is not supported on any objects. All factory functions on the document create transient objects (not Persistent), except createElement(NS) which creates Zope Folders. At ZServer startup, a transient document is created and set as the parent of the Application and ownerDocument of all Zope objects. TODO ------ 1. Fix alpha reported bugs. 2. Complete and test the document factory functions. 3. Implement and test cloneNode() 4. Complete unmapped/unimplemented DOM interface functins: nodeName nodeValue nodeType setParentNode

1 0

CatalogAwareness for RackMountables
by Itamar Shtull-Trauring 30 May '00

30 May '00

I've been playing around with ZPatterns, and I must say it's very cool - finally you can mix ZCatalog and SQL storage. CatalogAwareness is slightly different than regular Zope objects in that you have to find the ZCatalog in the Rack's acquisition path, but that's about it. The absolute_url function I define here should be moved to the RackMountable class since it may be useful in other situations. --------------------------------------------------------- from Products.ZCatalog.CatalogAwareness import CatalogAware from Products.ZPatterns.Rack import _v_rack, RackMountable class RMCatalogAwareMixIn(CatalogAware): """ CatalogAwareness for RackMountables. You need to inherit from this class before RackMountable. Objects are NOT automatically indexed, because no rack has been defined when we're in __init__. """ def absolute_url(self, relative=0): """ URL for catalog-awareness """ return "%s/%s" % (self._v_rack.absolute_url(relative), self.id) def index_object(self): """A common method to allow Findables to index themselves.""" if hasattr(self._v_rack, self.default_catalog): getattr(self._v_rack, self.default_catalog).catalog_object(self, self.url()) def unindex_object(self): """A common method to allow Findables to unindex themselves.""" if hasattr(self._v_rack, self.default_catalog): try: getattr(self._v_rack, self.default_catalog).uncatalog_object(self.url()) except: pass def manage_delete(self, _v_rack=_v_rack): """ Uncatalog this object and then delete it """ self.unindex_object() return RackMountable.manage_delete(self, _v_rack)

2 1

Re: [Zope-dev] Cataloging "LocalFS" content
by Rik Hoekstra 30 May '00

30 May '00

>> I think, cataloging "LocalFS" content would be nice. >> >> I have the following problems with it: >> >> 1. "LocalFS" defines various meta types: >> "Local File System", "Local Directory" and "Local File". >> >> Only "Local File System" is a "true" meta type which >> should appear in the available objects list of ObjectManager's. >> >> However, I may well be useful, to select the others, too, >> in for "find" and cataloging. > >This could be done, but my concern is that when changes are made to the file >system this will cause the catalog to be out of synch until you re-index. How >does this work with Zope objects? If you move or delete a Zope object that is >cataloged does it automatically update the catalog? Only if it is 'Catalog Aware', otherwise you'll have to update it manually. In the case of LocalFS this will always be the only way. Rik

1 0

Cataloging "LocalFS" content
by Dieter Maurer 30 May '00

30 May '00

Dear Zopistas, I think, cataloging "LocalFS" content would be nice. I have the following problems with it: 1. "LocalFS" defines various meta types: "Local File System", "Local Directory" and "Local File". Only "Local File System" is a "true" meta type which should appear in the available objects list of ObjectManager's. However, I may well be useful, to select the others, too, in for "find" and cataloging. 2. ZCatalog uses "bobo_modification_time" in its meta table and for indexing. For "LocalFS" content, this is not the best modification time to use for indexing. It would be nice, if "bobo_modification_time" could somehow be synchronized with the object's modification time in the file system. Can you give me some ideas how to best solve these problems. Dieter

2 1

Memory issue 2.1.1 request for info
by Jason Spisak 30 May '00

30 May '00

Matthew T. Kromer: > I'm extremely curious that the cache doesn't clear when you restart Zope. > One would normally not expect to see this. Can you do a "ps xauww" and mail > it to me / the list? USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.0 1104 72 ? S May26 0:05 init [3] root 2 0.0 0.0 0 0 ? SW May26 0:03 [kflushd] root 3 0.0 0.0 0 0 ? SW May26 0:02 [kupdate] root 4 0.0 0.0 0 0 ? SW May26 0:00 [kpiod] root 5 0.0 0.0 0 0 ? SW May26 0:03 [kswapd] root 6 0.0 0.0 0 0 ? SW< May26 0:00 [mdrecoveryd] root 9 0.0 0.0 0 0 ? SW May26 0:00 [scsi_eh_0] bin 330 0.0 0.0 1196 0 ? SW May26 0:00 [portmap] root 359 0.0 0.0 1156 144 ? S May26 0:00 syslogd -m 0 root 370 0.0 0.0 1396 0 ? SW May26 0:00 [klogd] daemon 386 0.0 0.0 1128 104 ? S May26 0:00 /usr/sbin/atd root 402 0.0 0.0 1304 108 ? S May26 0:00 crond root 418 0.0 0.0 1124 0 ? SW May26 0:00 [inetd] root 434 0.0 0.0 1176 0 ? SW May26 0:00 [lpd] root 457 0.0 0.0 2204 0 tty1 SW May26 0:00 [login] root 458 0.0 0.0 1076 0 tty2 SW May26 0:00 [mingetty] root 459 0.0 0.0 1076 0 tty3 SW May26 0:00 [mingetty] root 460 0.0 0.0 1076 0 tty4 SW May26 0:00 [mingetty] root 461 0.0 0.0 1076 0 tty5 SW May26 0:00 [mingetty] root 462 0.0 0.0 1076 0 tty6 SW May26 0:00 [mingetty] zope 465 0.0 0.0 1740 0 tty1 SW May26 0:00 [bash] root 498 0.0 0.0 2360 32 ? S May26 0:00 [in.rlogind] root 499 0.0 0.0 2288 0 pts/0 SW May26 0:00 [login] jason 500 0.0 0.0 1752 484 pts/0 S May26 0:00 -bash zope 1992 0.0 0.0 3188 0 tty1 SW May29 0:01 [python] zope 1996 0.0 22.2 220152 216340 tty1 S May29 1:33 /Zope/bin/python /Zope/z2.py -t 10 -D zope 1998 0.0 22.2 220152 216340 tty1 S May29 0:02 /Zope/bin/python /Zope/z2.py -t 10 -D zope 1999 0.0 22.2 220152 216340 tty1 S May29 0:00 /Zope/bin/python /Zope/z2.py -t 10 -D zope 2000 0.0 22.2 220152 216340 tty1 S May29 0:00 /Zope/bin/python /Zope/z2.py -t 10 -D zope 2001 1.4 22.2 220152 216340 tty1 S May29 23:39 /Zope/bin/python /Zope/z2.py -t 10 -D zope 2002 0.0 22.2 220152 216340 tty1 S May29 0:13 /Zope/bin/python /Zope/z2.py -t 10 -D zope 2003 0.0 22.2 220152 216340 tty1 S May29 0:08 /Zope/bin/python /Zope/z2.py -t 10 -D zope 2004 0.0 22.2 220152 216340 tty1 S May29 0:00 /Zope/bin/python /Zope/z2.py -t 10 -D zope 2005 0.0 22.2 220152 216340 tty1 S May29 0:42 /Zope/bin/python /Zope/z2.py -t 10 -D zope 2006 0.0 22.2 220152 216340 tty1 S May29 0:00 /Zope/bin/python /Zope/z2.py -t 10 -D zope 2007 0.0 22.2 220152 216340 tty1 S May29 0:00 /Zope/bin/python /Zope/z2.py -t 10 -D zope 2008 1.1 22.2 220152 216340 tty1 S May29 17:55 /Zope/bin/python /Zope/z2.py -t 10 -D root 2474 0.0 0.0 2360 0 ? SW 09:35 0:00 [in.rlogind] root 2475 0.0 0.0 2292 0 pts/1 SW 09:35 0:00 [login] jason 2476 0.0 0.0 1748 0 pts/1 SW 09:35 0:00 [bash] jason 2610 0.0 0.0 2508 864 pts/0 R 11:41 0:00 ps xauww The memory values are significantly smaller % for the threads than they were orignially. Shane had me set the "Target Time Between Accesses" to 3 seconds. I have futzed with it and now have it at 30 seconds. Also, the "target Size" was at 20,000 objects and now I have it at 10,000. >Also a "free" would be helpful too. total used free shared buffers cached Mem: 971452 966896 4556 2448 627104 92608 -/+ buffers/cache: 247184 724268 Swap: 128480 6732 121748 > Under linux, > shared memory is amongst the last to be scavenged in low memory conditions. > I'm curious to see if something is allocating that memory as shared or what. > > You might also try an "ipcs -a" command to make sure it's not SYSV type > shared memory (which can stick around even after a process exits.) ------ Shared Memory Segments -------- key shmid owner perms bytes nattch status ------ Semaphore Arrays -------- key semid owner perms nsems status ------ Message Queues -------- key msqid owner perms used-bytes messages Things are moving pretty speedilly since I adjusted the setcheckinterval. Thanks Matt!! I'll send the output of these commands after a Zope exit at the end of our intranet business here today. Just think, with ZEO I won't have to wait until the close of business ('cause the web is never closed:) Thanks again, -- Jason Spisak 444(a)hiretechs.com

1 0

RE: [Zope-dev] Ending up with a wrapped object through the web?
by Brian Lloyd 30 May '00

30 May '00

> > That did the trick. One oddity, though: I had to > reauthenticate as the > > superuser to do it. Shouldn't a Manager be able to import to > > Control_Panel/Products? > > worse yet - you can't import _at_ _all_ outside the control panel. > > A manager can't access RoleManager. superuser can't own objects. Ok - this should be fixed now in CVS. Part of the machinery that checks whether the user is really allowed to create the type of object they are importing was failing spuriously because it expected the object it was checking to be wrapped (which isn't the case when checking an imported object to see if it can be added). Update AccessControl/User.py to get the fix. Brian Lloyd brian(a)digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com

1 0

CatalogAwareness for RackMountables
by Itamar Shtull-Trauring 30 May '00

30 May '00

Sorry if this arrives twice, but mailing lists seem to have swallowed my earlier mail. I've been playing around with ZPatterns, and I must say it's very cool - finally you can mix ZCatalog and SQL storage. CatalogAwareness is slightly different than regular Zope objects in that you have to find the ZCatalog in the Rack's acquisition path, but that's about it. The absolute_url function I define here should be moved to the RackMountable class since it may be useful in other situations. --------------------------------------------------------- from Products.ZCatalog.CatalogAwareness import CatalogAware from Products.ZPatterns.Rack import _v_rack, RackMountable class RMCatalogAwareMixIn(CatalogAware): """ CatalogAwareness for RackMountables. You need to inherit from this class before RackMountable. Objects are NOT automatically indexed, because no rack has been defined when we're in __init__. """ def absolute_url(self, relative=0): """ URL for catalog-awareness """ return "%s/%s" % (self._v_rack.absolute_url(relative), self.id) def index_object(self): """A common method to allow Findables to index themselves.""" if hasattr(self._v_rack, self.default_catalog): getattr(self._v_rack, self.default_catalog).catalog_object(self, self.url()) def unindex_object(self): """A common method to allow Findables to unindex themselves.""" if hasattr(self._v_rack, self.default_catalog): try: getattr(self._v_rack, self.default_catalog).uncatalog_object(self.url()) except: pass def manage_delete(self, _v_rack=_v_rack): """ Uncatalog this object and then delete it """ self.unindex_object() return RackMountable.manage_delete(self, _v_rack)

1 0

RE: [Zope-dev] Ending up with a wrapped object through the web?
by Brian Lloyd 30 May '00

30 May '00

> > That did the trick. One oddity, though: I had to > reauthenticate as the > > superuser to do it. Shouldn't a Manager be able to import to > > Control_Panel/Products? > > worse yet - you can't import _at_ _all_ outside the control panel. > > A manager can't access RoleManager. superuser can't own objects. I'm looking into this now - stay tuned... Brian Lloyd brian(a)digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com

1 0