Re: [Zope-dev] Running methods on Zope startup.
On Apr 25 22:19, Myroslav Opyr <[EMAIL PROTECTED]> wrote: > > Subject: Re: [Zope-dev] Running methods on Zope startup. > > Chris McDonough wrote: > > >[snip] > > > There is product ZExternalNews which is working in background from Zope > startup. You can take a look there. There are several Startup issues in > the code. Yes, this product is doing a similar thing to what I want to do. I note though that it does: app=context._ProductContext__app Ie., it breaks abstraction and accesses the private application context which is available in the product context. Yes, it is possible, but it is (is it) cheating. :-) Is there any reason why the application context in the product context just can't be public in the first place? It would make things easier and doesn't seem that big a deal to change it. At least Zope could provide a public method which gives access to it. I also note that this product does what it needs direct from the product initialize routine. As long as this product doesn't rely in anyway on other products this would be okay, but if it did, it could be a problem as threads created by the product might try to access another product or even part of Zope which hadn't been initialised yet. Anyway, I might just break the encapsulation in the same way for now, will save a lot of work. Thanks for the pointer to this package. -- Graham Dumpleton ([EMAIL PROTECTED]) ___ 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] Running methods on Zope startup.
On Apr 25 10:02, Toby Dickenson <[EMAIL PROTECTED]> wrote: > > Subject: Re: [Zope-dev] Running methods on Zope startup. > > On Wed, 24 Apr 2002 21:56:52 -0600 (MDT), [EMAIL PROTECTED] wrote: > > >Imagine a situation similar to database connections. With database connections > >when you create it you can indicate that you want the connection established. > >Now when Zope is restarted, those database connections will be automatically > >restarted when Zope restarts. Although, I am not sure whether this is when > >Zope actually starts or when the next request using that database happens. > > The connection is made when the next request comes in, and the > connection is broken when ZODB decides it is time to deactivate the DA > object; which is hopefully only happens if the connection has not been > used for a while. Ok, wasn't quite sure which way it did it. > >I can't rely on > >the connection only starting when someone tries to access the resource, I > >want it to happen straight away upon Zope restart. > > I think you will have to fight ZODB if you need: > * The connection to always stay up > * one connection per instance of a class stored in ZODB > (like database adapters) On the latter point of searching automatically for all instances of a particular type and automatically starting up something for it, that was my first thought and in the end I figured that could get real inefficient. That is when I came to the lowest common denominator of a "Startup" folder and figured that a manual association could be made. At least an association with a product instance which could then do the hard work. Anyway, I know I will potentially have to fight ZODB though, as I can see lots of instances where I will need to recognise existance of objects in ZODB and create parallel transient objects which do something in relation to those instances. Given I am new to Zope this might turn out to be messier than I think it will. > >Can anyone point me to such a Zope product. I have started looking at how > >to do it myself and have some of the bits in place. The first issue is that > >when the "initialize()" method in the product "__init__.py" file is called > >not all Zope startup has occured, so it is too early to trigger things from > >that point. > > Initialize looks like the right place to me. What do you think this is > too early for? Not all products might have been initialized at that point, plus possibly other stuff as well in Zope itself. The asyncore loop also isn't running at that point. For reasons unknown I have also already found that if I create some separate code of my own from a thread started in the initialize routine, that even though the main thread of control returned back into Zope to finishing doing everything and start up asyncore, Zope wouldn't then service any requests. Was most strange, would only work if I created the separate thread from callback in asyncore once it had been started. > One thing that might be nice to add is *dependencies* between product > initialization. Today you have to rely on Zope sorting product names > alphabetically before initialization, which slightly sucks. This is an issue with the idea of a "Startup" folder as well as what order to you execute register methods. First thought was to have ability to say that method relied on other method being run first, but then figure that for simplicity, might be easier to let user indicate specific order they were run through management interface. > >The next problem is getting an appropriate context to be able to start making > >calls into Zope objects. The "initialize()" method gets a product context, > >but doesn't have public access to the application context. Is there some way > >of accessing the Zope application context and thus root folder where you > >don't otherwise have a handle to it? > > Public access? no. currently you have to hack through the jar. > > I agree there should be an API for this. But then, as suggested by someone else, if a startup mechanism is inbuilt the hook would be placed in the Application.py file which has access to the application context anyway. Feedback appreciated. -- Graham Dumpleton ([EMAIL PROTECTED]) ___ 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] Running methods on Zope startup.
On Apr 25 00:57, "Chris McDonough" <[EMAIL PROTECTED]> wrote: > > Subject: Re: [Zope-dev] Running methods on Zope startup. > > Something like this is slated for Zope 2.6. If possible (and that's a big > if at the moment, with the work we've got lined up), it is my intention to > create a service which does the following: > > ... > > The two things that I think are different about this than what you specified > is that in my conception, the startup folder is not a persistent Zope > object, and you would need to place files in a directory on disk to hook the > startup process. It also solves the problem of needing to have a handle to The important thing as far as I can see is that the hook is at least there in such a way that the application context is available. As long as one has that, it would then be very easy to add in a method which went looking for the "Startup" folder in the database and went from there. > I think your idea of registering a callback to ensure that startup is > complete before performing any actions is very sound. I think a callback > can be registered almost anywhere, but a plausible place to create the > registration method might be in lib/python/OFS/Application.py. Then the > callback should probably be called by lib/python/Zope/__init__.py (somewhere > after "OFS.Application.initialize(c)", after which point all Products should > be initialized). Yes, worked out where it could be done, for now I was trying to work out how it might be done without modifying the Zope code. > This is a little brittle, though. A better way to do this would be to > create a generic Zope scheduling module. This is where hooking the asyncore > mainloop would be very appropriate. Unfortunately, the implementation is a > bit more complex because you'd probably need to make sure the scheduler > didn't hold up the mainloop, and that means kicking off one or more threads > to do the work instead of using the main thread just at startup. However, > it would be much more generally useful and forward-thinking to implement it > this way, even if it was a stub that didn't actually do anything but startup > stuff at first. As long as one has the startup hook, a scheduler can then be a Zope product. Steps would then be for someone to install "Startup" product and if need be manually register callback in internal Zope startup directory to execute "Startup" folder in known location. Someone installing the "Scheduler" product would then register instance of it with "Startup", or it could even be automatic in some way by using registration ability of ZCatalog. In respect of a separate thread, I agree. I actually already have a full scheduler/dispatcher written I can hook in. It actually has its own select loop and thus must be run in a separate thread. It even has mechanism to be woken up from select if new job was scheduled to be running but dispatcher was otherwise blocking. The only issue with this separate dispatcher is that the core is actually written in C++ and isn't pure Python but relying on Python wrappers that already exist. > If I were to do this, I would: > > - Implement a stub scheduler module that was really dumb and only > knew how to do "run once, now" jobs (no run-many jobs, no run-then > jobs). Do this so as to not go insane trying to reinvent cron and at > at the moment. ;-) I already have the cron code in the dispatcher system I have. :-) > - Implement a non-Product "Startup" module that did what I explain above, > but registered a callback with the scheduler instead of with > the method called by Zope/__init__. > > - Change medusa's asyncore so that the "poll" (and poll2, and poll3) > function kept track of when the scheduler had last been run. How is that important if it is run in a separate thread? > - In asyncore, when either the select call times out or the last time the > schduler was run was over "X" seconds in the past, call in to > the scheduler, telling it to wake up, modifying the "last run" time. Hmmm, still not sure why, but then the dispatcher code I have probably has a much more developed job model than asyncore does. Not only does it support i/o activity, timeouts, alarms, cron alarms, it also has three different types of jobs, ie., priority, standard and idle. Add to that that it has a separate thread, not sure why they would need to communicate. > - The (dumb) scheduler would wake up and notice that it had a job and > would kick off a thread which would call back in to the startup code. > Then it would remove the job from its queue and go on with its life, > which would be absolutely desolate until the next time Zope started up. > > This architecture would facilitate innovations (like a *real* scheduling > facility ;-) in the future. Which is what I am interested in now. Right now though, I am more interested in what is using the dispatcher in parallel to Zope as opposed to scheduling persistent met
[Zope-dev] localRoles
Hi, if I define local roles for a folder object. Are the local roles acquired by Objects in the folder and sub-folders and so on ? Regards, Dirk ___ 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] python question
Hi, does anybody know a good programm or the command to create documentation of python classes (api-documentation like javadoc) out of the python code ? Thanks, Dirk ___ 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] RE: [ZC] 365/ 2 Reject "metadata in Catalog is space inefficient"
Toby Dickenson wrote: > > Note that this scheme may not necessarily give runtime performance > benefits. Loading the reverse index data may not be any faster than > loading metadata. I'm betting in a lot of cases it'll be a damn site slower. MetaData is specifically designed to be real quick to load. For the small extra space usage (how much _does_ disk space, or RAM for that matter, cost nowadays?! ;-), I'm more than happy to take the speed win... 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] RE: [ZC] 365/ 2 Reject "metadata in Catalog is space inefficient"
On Fri, 26 Apr 2002 09:02:26 +1000, "Jay, Dylan" <[EMAIL PROTECTED]> wrote: >I specifically stated a FieldIndex, not TextIndex. It is a special case, Yes. KeywordIndex too, although you lose ordering information. >but >when your talking a huge Catalog this could be a lot of extra data. Under your proposal data would be stored two times (original object, plus index) rather than three times (metadata too). A saving of 2:3, assuming the original object is no larger than the sum of its indexed properties. In most cases the original object is bigger, and it will probably add up to no more than a few percent of disk space. Are there any common scenarios where the margin would be bigger? Note that this scheme may not necessarily give runtime performance benefits. Loading the reverse index data may not be any faster than loading metadata. Toby Dickenson [EMAIL PROTECTED] ___ 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] RE: [ZC] 365/ 2 Reject "metadata in Catalog is space inefficient"
I specifically stated a FieldIndex, not TextIndex. It is a special case, but when your talking a huge Catalog this could be a lot of extra data. If you want to make it more general, perhaps a PluginIndex could advertise itself as "metadata" capable. When someone adds a metadata field it checks to see if an existing index supports returning of metadata for an RID. > -Original Message- > From: Collector: Zope Bugs, Features, and Patches ... > [mailto:[EMAIL PROTECTED]] > Sent: Thursday, 25 April 2002 6:32 PM > To: djay; chrisw; klm; Brian; chrism; Caseman; _Rejected_ recipient > Subject: [ZC] 365/ 2 Reject "metadata in Catalog is space inefficient" > > > Issue #365 Update (Reject) "metadata in Catalog is space inefficient" > Status Rejected, Catalog/bug low > To followup, visit: > http://collector.zope.org/Zope/365 > > == > = Reject - Entry #2 by chrisw on Apr 25, 2002 4:31 am > > Status: Pending => Rejected > > You're making a huge assumption there. > > In many cases, I'm thinking TextIndex being the primary > example here, it's not actually possible, let alone feasible, > to retrieve the originally indexed information from the index itself. > > So your point is kidna invalid ;-) > > cheers, > > Chris > > = Request - Entry #1 by djay on Apr 25, 2002 3:52 am > > If I create a metadata to be stored so that it is availalbe > in my results, and this metadata is the same as a FieldIndex, > then the data is effectively being stored twice for no > reason. The value of the metadata should just be retrieved > from the index to save space > == > > ___ 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] Re: [OT] digital signature
On Thu, 2002-04-25 at 18:19, Martijn Pieters wrote: > On Thu, Apr 25, 2002 at 06:02:19PM +0200, Lennart Regebro wrote: > > I want a *good* mail program. :-/ > > I can recommend Mutt. ;) for those who are used to OE I'd recommend Ximian Evolution :) ___ 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] PHP is to Perl as Java is to C++
"Don Hopkins" <[EMAIL PROTECTED]> writes: > The fact that sombody's invested years in learning C++ or Perl is no > justification for spreading the disease, when there are better more > appropriate solutions available for free. accepted. Nicola Larosa <[EMAIL PROTECTED]> writes: > This is great advocacy, but maybe a little too inflammatory, and "spreading > the disease" is going a little too far. Anyway, I mostly agree on what you > said, as most around here, I presume. > > The problem is, these points are true from the general point of view, but > are unhelpful, and probably dangerous, when you have to confront developers > already attached to such broken languages. Or decision makers, who decide development Platforms for a Project (which most often are *not* the developers). I am not free to choose my Platform. It's sad, but it's a fact. If I could, I would do most of my development in lisp (I love it). But its neigh impossible to get someone to support lisp. Especially when you are forced to interface with the (non)standards of some unnamed proprietary entity ;-/... So most of the Time, the choice of languge/development Platform is by what is supported by the necessary surrounding technologies. At least that's how it is here. Stefan. ___ 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 )
