[Zope-dev] Inheritable properties(sheets)? Anyone? Anyone? Bueller?
I want to inherit the properties of one zclass in another zclass, but it seems to cause some namespace clashing... shouldn't this be possible? Working with the instance of the class is fine, but inter-zclass inheritance (acquisition?) would be nice... Am I missing something? Thanks, Alex. 1010011010101001101010100110101010011010 0 Digital Garage$B!!%G%8%?%khttp://www.zope.ne.jp/ http://www.garage.co.jp ___ 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] Strange permissions in the (built-in) API reference
Dieter Maurer wrote: > > Recently, I read the "Interface Wiki". It covers most of > the methods contained in the API and its permission descriptions > made a very solid impression. Maybe, you can start from these > descriptions. The Interfaces Wiki is actually where all the API documention did come from. Are there inconsistencies? > It might also not be optimal wrt. maintainability > that the modules, their classes and their methods with > the respective docstrings have been recreated > just for API documentation purposes. > Probably, it would be preferable to use the docstrings > and the method prototypes from the source directly. > You might still want to control with methods are described > in the API and in which order. > Personally, I would control this, too, inside the source > documentation (a la javadoc), but I can imagine that an > external configuration might be advantageous. Yes, there are pros and cons on both sides, and Amos, Jim and I had some long converstations about this very subject. We decided to go with seperate documentation instead of autogenerating it because: 1. An interface should be a contract, not just an artifact of the code. 2. Python, being without first class support for interfaces, has no clear way of spelling an interface of a class. 3. Jim is working on formal interface support for python and he's thinking hard about it, we definatly didn't want to think hard about it and then turn out we came up with a bad answer, the existing API docs are just that, docs, not interfaces. When format interfaces come about, API docs will probably be converted to that format. Thanks for the comments! -Michel ___ 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] Xron fragility
> > Do you think this is this any more effective than having a producer thread > > do a lookup every minute to see what jobs are current, after which it should > > put the current jobs in a queue? E.g., as the "run" method of a separate > > producer thread: > > the same problem applies, a solution might be a timer and a signal > handler to catch a signal event when a new job is entered into the > system. events could be managed as some sort of collection of linked > lists (or whatever ds). I think this problem is solved by: - polling for "current" events every 60 seconds *exactly on the 0th second of the minute* (this ensures that stopping and starting the scheduler won't accidently cause a "current" repeating event to fire twice). - allowing one-time events (which are most likely to need to be executed immediately) to be "current" for the minute implied by the event's timestamp as well as the minute just before that one. This ensures that an event that has a timestamp that was "current" when entered, but has subsequently been passed due to event polling overhead will be executed (even if it is entered at hh:mm:59.999 or similar). It also assumes that the scheduling poller will never take more than 60 seconds to poll all events, which is a fairly safe assumption. - the executor of the event is required to invalidate one-time events once they've been executed (or before they're executed) so they don't get fired twice. I don't believe there is any need for a signal handler or anything of the sort, the problem seems to just require careful synchronization. > i played around with this in a monitor thread and you just can't achieve > the proper semantics to execute an arbitray zope method. you have to > recreate the request, response as well as have all the required support > modules (DTML, tracebacks, etc) to successfully call a method, you are > in essence reduplicating the publishing machinery. i tried to think of a > way to get around this but i came up short. you can still access > variables and simple methods. This would need to be thought through... the same problem exists for unit testing. :-( > > I see... would it be naive if I were to say that I think that a scheduler > > should fire off threads of its own and not rely on an external facility to > > run the jobs? > > the dispatcher thread itself has a connection to the ZODB, its using > client as RPC to invoke the methods on Publishing threads. Since there > is a hardcoded limit to ZODB connections firing off more connections > does not seem like a good idea. AFAIK, threads will block if they can't get a DB connection. What risks does that imply? Is it a problem? ___ 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] Xron fragility
A smoke break later, some possible more thoughts and snake oil, there are two general purpose facilities embodied in xron that i would like to see made available as zope services, async zope processing and scheduling. async-- i'd like to be able to designate TTW that a method execute outside of the current request/response pair to do some long/heavy processing. the design might be easier if this functionality was separated out. a small dynamic pool of publishing threads to execute async functionality (hmmm.. why reinvent the wheel, zope threads are already in place... but what are the consequences of tying up the fixed number of zope's standard publishing threads on a busy site). and a scheduling thread to manage scheduled events/scheduling and dispatching to publishing threads. the possiblities of such are complicated by the magic number limit of thread connections to the ZODB. I was wondering how this magic number came about, is it a performance number dictated by the python interpretor lock? ___ 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] Xron fragility
Chris McDonough wrote: > > > > > > Xron has a single dispatcher thread. This thread knows how long to > sleep > > > > for until the next job needs to run. > > > > > > Do you think this is this any more effective than having a producer > thread > > > do a lookup every minute to see what jobs are current, after which it > should > > > put the current jobs in a queue? > > > > What if you want a small job to be done every 30 seconds? > > I generally don't... I'm satisfied with cron granularity, although others > might not be. Do you have this requirement? > > > > > It uses Client.py to run a job. > > > > > > Why is this? This doesn't make any sense to me on its face. Why not > just > > > call the method from a separate thread? > > > > Which separate thread? Do you create a new ZODB thread? That sounds as > > if it might use quite a few resources. > > > > Is there a Zope API for making ZODB threads call methods on objects, as > > signalled by other threads? I'm guessing the easiest way to do that is > > to use Client.py to make a new http request. > > Well... AFAIK, there is no such thing as a ZODB thread... there are a number > of Python threads used by Zope. We'd just fire off another one to perform a > task as part of the thing that takes an event off the queue. This might be > naive. I need to try it. the real problem with a scheduler thread redesign is being able to call a zope method directly through a zodb connection (and also the connection limit). the zpublishing machinery is sitting atop the zodb, and to really make the method work you need to reduplicate it AFAIK. This just seems inescapable to me as its fundamental to the way zope works, i'd love to be enlightened... Kapil ___ 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] Xron fragility
Chris McDonough wrote: > > > It is the Xron DTML Method's responsibility to reschedule itself. > > It could be its first duty, however. Then again, as all the work happens > > inside a ZODB transaction, it doesn't matter when the reschedule > > happens. > > I understand. > > As a side note, I do not like the fact that Xron requires you to use special > DTML methods. I suppose this is a requirement in this architecture due to > the fact they need to be autocataloged, but I don't really like that feature > either :-). My two biggest problems with the XRON facility are the Catalog and the need for speciality methods. I was thinking a more useful model might be something along the lines of a unix cron. each user having access to their own cron tab, via some manage methods, and the methods listed would execute as the user. the hole trigger/disarm methodology to me seems a bit hokey and fragile. i can see the utility in offering up traditional zope semantics of users creating objects, but i really think that scheduling is something that should be part of the core and offered as a service to users. > > > What does the Dispatcher thread do? Does it fire off worker threads? > > > > Xron has a single dispatcher thread. This thread knows how long to sleep > > for until the next job needs to run. this model has problems when new jobs (for immeadiate execution) are entered after the system sleeps. i think it should it taken into account that people will use this dispatching thread to achieve async operations on a request, and that these might need to be done immeadiately. > Do you think this is this any more effective than having a producer thread > do a lookup every minute to see what jobs are current, after which it should > put the current jobs in a queue? E.g., as the "run" method of a separate > producer thread: the same problem applies, a solution might be a timer and a signal handler to catch a signal event when a new job is entered into the system. events could be managed as some sort of collection of linked lists (or whatever ds). > def run(self,localtime=time.localtime,time=time.time,sleep=time.sleep): >while 1: > t = localtime(time()) > sleeptime = (60 - t[SECOND]) > sleep(sleeptime) > for event in self.eventdata.values(): > if event.isCurrent(): > > self.outputqueue.put(EventWrapper(event,self.reportqueue)) > > > It uses Client.py to run a job. > > Why is this? This doesn't make any sense to me on its face. Why not just > call the method from a separate thread? i played around with this in a monitor thread and you just can't achieve the proper semantics to execute an arbitray zope method. you have to recreate the request, response as well as have all the required support modules (DTML, tracebacks, etc) to successfully call a method, you are in essence reduplicating the publishing machinery. i tried to think of a way to get around this but i came up short. you can still access variables and simple methods. > > > What are other threads in Xron doing while the Dispatcher thread is > hosed? > > > What are the other threads? > > > > There are no other threads in Xron. > > Xron creates a single thread to do all event dispatching. The work is > > done in Zope ZODB threads (or whatever the correct terminology is). The > > dispatcher thread communicates with a ZODB thread by using Client to > > make a web request. > > I see... would it be naive if I were to say that I think that a scheduler > should fire off threads of its own and not rely on an external facility to > run the jobs? the dispatcher thread itself has a connection to the ZODB, its using client as RPC to invoke the methods on Publishing threads. Since there is a hardcoded limit to ZODB connections firing off more connections does not seem like a good idea. > > Xron usually makes requests as the anonymous user. However, I've patched > > my Xron to make requests as XronUser by hardcoding (!) the username and > > password for that in the RPC.py module of Xron. Then, I've manually > > created a XronUser user in my root user folder. I give XronUser the > > local roles needed to run methods I want to be scheduled via Xron. > > If this were handled not using Client.py, I think we could just use the > security manager to change users. the xron dispatcher has access to ZODB attrs, and simple methods. the security manager would probably need to support semantics of retrieving passwords so they can be set in the client. btw, i'm interested in seeing scheduling get into the zope core as well. Kapil ___ 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] Xron fragility
> I'll need to try to call get_transaction().commit() from a > manually-constructed Python thread fired off from Zope and see what happens. > I think it'll just work. I'll find out in a few minutes. :-) Yes, it just works. :-) ___ 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] Xron fragility
> > As a side note, I do not like the fact that Xron requires you to use special > > DTML methods. I suppose this is a requirement in this architecture due to > > the fact they need to be autocataloged, but I don't really like that feature > > either :-). > > I think Xron could work with anything that has "trigger" and "disarm" > methods, that gets put into the Schedule catalog. I guess I'm not real real hot on the dependency on a catalog at all. I'm having a hard time imagining a situation where you have so many events that you need to index them -- especially using a ZCatalog. It just seems like too many moving parts and overkill for the job. :-) > > > Xron has a single dispatcher thread. This thread knows how long to sleep > > > for until the next job needs to run. > > > > Do you think this is this any more effective than having a producer thread > > do a lookup every minute to see what jobs are current, after which it should > > put the current jobs in a queue? > > What if you want a small job to be done every 30 seconds? I generally don't... I'm satisfied with cron granularity, although others might not be. Do you have this requirement? > > > It uses Client.py to run a job. > > > > Why is this? This doesn't make any sense to me on its face. Why not just > > call the method from a separate thread? > > Which separate thread? Do you create a new ZODB thread? That sounds as > if it might use quite a few resources. > > Is there a Zope API for making ZODB threads call methods on objects, as > signalled by other threads? I'm guessing the easiest way to do that is > to use Client.py to make a new http request. Well... AFAIK, there is no such thing as a ZODB thread... there are a number of Python threads used by Zope. We'd just fire off another one to perform a task as part of the thing that takes an event off the queue. This might be naive. I need to try it. > I'd really like to see a scheduler as a standard part of Zope. > I think it would be good to have scheduled methods called from within > Zope, rather then going through http. I don't know enough about how > ZPublisher/ZODB works to know where to start this though. I'll need to try to call get_transaction().commit() from a manually-constructed Python thread fired off from Zope and see what happens. I think it'll just work. I'll find out in a few minutes. :-) ___ 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] Xron fragility
Chris McDonough wrote: > > As a side note, I do not like the fact that Xron requires you to use special > DTML methods. I suppose this is a requirement in this architecture due to > the fact they need to be autocataloged, but I don't really like that feature > either :-). I think Xron could work with anything that has "trigger" and "disarm" methods, that gets put into the Schedule catalog. > > > What does the Dispatcher thread do? Does it fire off worker threads? > > > > Xron has a single dispatcher thread. This thread knows how long to sleep > > for until the next job needs to run. > > Do you think this is this any more effective than having a producer thread > do a lookup every minute to see what jobs are current, after which it should > put the current jobs in a queue? What if you want a small job to be done every 30 seconds? > > It uses Client.py to run a job. > > Why is this? This doesn't make any sense to me on its face. Why not just > call the method from a separate thread? Which separate thread? Do you create a new ZODB thread? That sounds as if it might use quite a few resources. Is there a Zope API for making ZODB threads call methods on objects, as signalled by other threads? I'm guessing the easiest way to do that is to use Client.py to make a new http request. > I see... would it be naive if I were to say that I think that a scheduler > should fire off threads of its own and not rely on an external facility to > run the jobs? I'd really like to see a scheduler as a standard part of Zope. I think it would be good to have scheduled methods called from within Zope, rather then going through http. I don't know enough about how ZPublisher/ZODB works to know where to start this though. -- 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] Better user management: Usership vs. Membership
Jonas Juselius wrote: > > Hello, > > I had a look at the Membership product, but I could not get it to work. It > seems that the PortalMember ZClass in the PortalMembership Product inherits > from _ZClass_for_LoginUser, which is no longer in the LoginManager... Were you trying to use Membership with a CVS verson of LoginManager? Membership 0.7.6 works with LM 0.8.7a and ZPatterns 0.4.1snap1. > But > actually I don't care... I tried to contact Bill about the Membership Prod, > but he seems to be unreachable because his mail address doesn't work. Bill just got married, was in the middle of changing network providers, and his old provider screwed up their IP addressing (on his wedding day). He says that he'll be back up Thursday or Friday. > I found many nice ideas in the Membership product, and I think it would really > be a good idea to develop it further. Does anybody know about any recent > developments or what the current status is? Is there going to be a new > release soon, is anyone even working on the Membership product? Bill is currently working on re-integrating Membership with the PTK. I recently found a way of integrating Membership+LM with the local roles interface. I also modified my copy of Membership to authenticate off of an NT PDC via SMB from a Solaris box. Most LoginManager and Membership discussion happens on the Zope-PTK mailing list, not Zope-Dev. Cheers, Michael Bernstein. ___ 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] Xron fragility
> It is the Xron DTML Method's responsibility to reschedule itself. > It could be its first duty, however. Then again, as all the work happens > inside a ZODB transaction, it doesn't matter when the reschedule > happens. I understand. As a side note, I do not like the fact that Xron requires you to use special DTML methods. I suppose this is a requirement in this architecture due to the fact they need to be autocataloged, but I don't really like that feature either :-). > > What does the Dispatcher thread do? Does it fire off worker threads? > > Xron has a single dispatcher thread. This thread knows how long to sleep > for until the next job needs to run. Do you think this is this any more effective than having a producer thread do a lookup every minute to see what jobs are current, after which it should put the current jobs in a queue? E.g., as the "run" method of a separate producer thread: def run(self,localtime=time.localtime,time=time.time,sleep=time.sleep): while 1: t = localtime(time()) sleeptime = (60 - t[SECOND]) sleep(sleeptime) for event in self.eventdata.values(): if event.isCurrent(): self.outputqueue.put(EventWrapper(event,self.reportqueue)) > It uses Client.py to run a job. Why is this? This doesn't make any sense to me on its face. Why not just call the method from a separate thread? > > What are other threads in Xron doing while the Dispatcher thread is hosed? > > What are the other threads? > > There are no other threads in Xron. > Xron creates a single thread to do all event dispatching. The work is > done in Zope ZODB threads (or whatever the correct terminology is). The > dispatcher thread communicates with a ZODB thread by using Client to > make a web request. I see... would it be naive if I were to say that I think that a scheduler should fire off threads of its own and not rely on an external facility to run the jobs? > Xron usually makes requests as the anonymous user. However, I've patched > my Xron to make requests as XronUser by hardcoding (!) the username and > password for that in the RPC.py module of Xron. Then, I've manually > created a XronUser user in my root user folder. I give XronUser the > local roles needed to run methods I want to be scheduled via Xron. If this were handled not using Client.py, I think we could just use the security manager to change users. ___ 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] Xron fragility
Chris McDonough wrote: > > Steve, > > I am also interested in scheduling... though I haven't looked closely at > Xron. > > > The Xron product seems rather "fragile" in use. > > > > That is, if things go wrong when an Xron DTML Method is triggered, that > > method doesn't get rescheduled. > > Does Xron take an optimistic approach to repeating jobs? In other words, > does it assume every job is a one-time job and that the last duty that a > repeating job performs is to reschedule itself? It is the Xron DTML Method's responsibility to reschedule itself. It could be its first duty, however. Then again, as all the work happens inside a ZODB transaction, it doesn't matter when the reschedule happens. > What does the Dispatcher thread do? Does it fire off worker threads? Xron has a single dispatcher thread. This thread knows how long to sleep for until the next job needs to run. It uses Client.py to run a job. Jobs are Xron DTML Methods. They have a "trigger" method that gets called through the web from localhost, by the Dispatcher thread. > > Before I leap in and start patching Xron, I'd like to have a discussion > > about how Xron should handle problems. > > > > My first thought is that on errors in the dispatcher thread, Xron should > > enter an "error state" where it probes every so often to see whether it > > can resume normal operation. The length of time between probes could > > increase with each probe, to give good performance with transient > > problems whilst preventing Xron from choking resources. > > What are other threads in Xron doing while the Dispatcher thread is hosed? > What are the other threads? There are no other threads in Xron. Xron creates a single thread to do all event dispatching. The work is done in Zope ZODB threads (or whatever the correct terminology is). The dispatcher thread communicates with a ZODB thread by using Client to make a web request. Xron usually makes requests as the anonymous user. However, I've patched my Xron to make requests as XronUser by hardcoding (!) the username and password for that in the RPC.py module of Xron. Then, I've manually created a XronUser user in my root user folder. I give XronUser the local roles needed to run methods I want to be scheduled via Xron. This is not the ideal way to make Xron use authentication. I posted a proposed design for that to zope-dev in August. http://lists.zope.org/pipermail/zope-dev/2000-August/006548.html http://lists.zope.org/pipermail/zope-dev/2000-August/006549.html http://lists.zope.org/pipermail/zope-dev/2000-August/006550.html -- 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] Xron fragility
Steve, I am also interested in scheduling... though I haven't looked closely at Xron. > The Xron product seems rather "fragile" in use. > > That is, if things go wrong when an Xron DTML Method is triggered, that > method doesn't get rescheduled. Does Xron take an optimistic approach to repeating jobs? In other words, does it assume every job is a one-time job and that the last duty that a repeating job performs is to reschedule itself? > An example of this is that my intranet DNS server needed to be rebooted. > Xron couldn't look up the appropriate domain name, and stopped working. > > -- > 2000-10-11T08:16:34 PROBLEM(100) Products.Xron.Loggerr > Trigger event: http://my.development.server:4080/my_xron_method > Trigger time: 2000/10/11 09:14:00 GMT+1 > Failed to trigger event. > Type=bci.NotAvailable > Val=host not found (File: > http://my.development.server/my_xron_method/trigger Line: []) > None None for None > -- > 2000-10-11T08:19:04 PROBLEM(100) Products.Xron.Loggerr Failed to disarm > event > > > Also, if something bad happens in the Dispatcher thread, the thread > dies. What does the Dispatcher thread do? Does it fire off worker threads? > Before I leap in and start patching Xron, I'd like to have a discussion > about how Xron should handle problems. > > My first thought is that on errors in the dispatcher thread, Xron should > enter an "error state" where it probes every so often to see whether it > can resume normal operation. The length of time between probes could > increase with each probe, to give good performance with transient > problems whilst preventing Xron from choking resources. What are other threads in Xron doing while the Dispatcher thread is hosed? What are the other threads? ___ 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] Xron fragility
The Xron product seems rather "fragile" in use. That is, if things go wrong when an Xron DTML Method is triggered, that method doesn't get rescheduled. An example of this is that my intranet DNS server needed to be rebooted. Xron couldn't look up the appropriate domain name, and stopped working. -- 2000-10-11T08:16:34 PROBLEM(100) Products.Xron.Loggerr Trigger event: http://my.development.server:4080/my_xron_method Trigger time: 2000/10/11 09:14:00 GMT+1 Failed to trigger event. Type=bci.NotAvailable Val=host not found (File: http://my.development.server/my_xron_method/trigger Line: []) None None for None -- 2000-10-11T08:19:04 PROBLEM(100) Products.Xron.Loggerr Failed to disarm event Also, if something bad happens in the Dispatcher thread, the thread dies. Before I leap in and start patching Xron, I'd like to have a discussion about how Xron should handle problems. My first thought is that on errors in the dispatcher thread, Xron should enter an "error state" where it probes every so often to see whether it can resume normal operation. The length of time between probes could increase with each probe, to give good performance with transient problems whilst preventing Xron from choking resources. -- Steve Alexander Software Enigneer 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 )
[Zope-dev] AttributeProvider and type information
I just want to ask a couple quick questions... First, when using the AttributeProvider class you are pretty much required to subclass it to add methods for altering the values of the attributes. Basically I want to be sure I'm not missing something criticle as there don't seem to be any methods on the default dataskin class for this (as there are for propertysheets)... and it seems like there should be. Related to this is dealing with typing information like PropertySheets used (via the _properties attribute). Wouldn't make sense to keep the AttributeProvider consistent with this... instead of the simple Attributes list? Seems like the type information and other meta information would as useful for handling attributes on the dataskin as for propertysheets. -- John Eikenberry [[EMAIL PROTECTED] - http://zhar.net] __ "A society that will trade a little liberty for a little order will deserve neither and lose both." --B. Franklin ___ 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] Better user management: Usership vs. Membership
Hello, I had a look at the Membership product, but I could not get it to work. It seems that the PortalMember ZClass in the PortalMembership Product inherits from _ZClass_for_LoginUser, which is no longer in the LoginManager... But actually I don't care... I tried to contact Bill about the Membership Prod, but he seems to be unreachable because his mail address doesn't work. I found many nice ideas in the Membership product, and I think it would really be a good idea to develop it further. Does anybody know about any recent developments or what the current status is? Is there going to be a new release soon, is anyone even working on the Membership product? I also looked in dev.zope.org, and found proposals about a new user management system for Zope. Does anybody know anything about this? What I would like, is to take the Membership product and turn it into a flexible 'Usership' product. This would mean simplifying the Membership by removing all the joining stuff and the like, and instead concentrate on building a nice user management environment for user admins (which need not necessarily be 'Manager'). Here is a list of things that I would like to see: * users would be able to log in via a nice login screen * users have user info attached to them, which they may or may not change * users can change their passwords * adding users is not automatic (the user manager adds and removes users) * possibility to automatically create properly protected home dirs for users * perhaps logging of user activity My main point is that I think most sites are not interested in Membership in a Portal or half-Portal sense, but would like to be able to set up a nice env for their content managers/designers and other users who just log in to access restricted info like on an intranet... One of my main concerns is that I'm wasting my time... Many of the underlying products for a better user management system are still evolving rapidly, and anything built on top of these, is likely to break many times. Also, since there has already been discussions about a new user system, someone might already be working on it, and have better ideas. I would also be interested in hearing what DC has to say, and what their plans are... Best regards, jonas -- And what is good, Phaedrus, And what is not--- Need we ask anyone to tell us these things? [ PGP public key: http://www.iki.fi/jonas/pubkey.asc ] ___ 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] Building Zope on Linux
On Wed, 11 Oct 2000 07:57:52 +0800, "Sin Hang Kin" <[EMAIL PROTECTED]> wrote: >Recently I report the MyMath.h is missing. After receiving the help from the >list, I realize I have just got the python 2.0 beta from the sourceforge >cvs. the file must have been removed from python. > >Are there any branch of Zope which is intended to run on Python2? I would >like to propose a new branch for python 2 support on the cvs. You dont need to use Zope's own version of cPickle and cStringIO with Python 2.0 - the versions supplied with Python are newer. (Zope included these special versions because 1.5.2 was not new enough) 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] Xron on linux: Dispatcher thread stops after a while
Zope 2.2.2, Xron-0-0-9, Python 1.5.2 I'm running this on i386 Linux. I run a development server, with that server running in debus mode (-D). I also run a production server, which runs detached from any console. When I use Xron for a while on my development server, I get the text currentThread(): no current thread for 2051 or something similar printed out to the console. This is caused by a harmless looking debugging line in /usr/lib/python1.5/threading.py Line 523 onwards: def currentThread(): try: return _active[_get_ident()] except KeyError: print "currentThread(): no current thread for", _get_ident() return _DummyThread() My development server just emailed me an error (from standard_error_message): Traceback (innermost last): File lib/python/ZPublisher/Publish.py, line 171, in publish File lib/python/ZPublisher/mapply.py, line 160, in mapply (Object: trigger) File lib/python/ZPublisher/Publish.py, line 112, in call_object (Object: trigger) File lib/python/Products/Xron/XronDTMLMethod.py, line 126, in trigger (Object: purge_pending_bookings) File lib/python/Products/Xron/XronDTMLMethod.py, line 153, in arm (Object: purge_pending_bookings) File lib/python/Products/ZCatalog/CatalogAwareness.py, line 193, in reindex_object (Object: purge_pending_bookings) File lib/python/Products/ZCatalog/CatalogAwareness.py, line 189, in unindex_object (Object: purge_pending_bookings) File lib/python/Products/Xron/Schedule.py, line 99, in uncatalog_object (Object: Traversable) File /var/tmp/python/python-root/usr/lib/python1.5/threading.py, line 287, in set File /var/tmp/python/python-root/usr/lib/python1.5/threading.py, line 233, in notifyAll File /var/tmp/python/python-root/usr/lib/python1.5/threading.py, line 215, in notify File /var/tmp/python/python-root/usr/lib/python1.5/threading.py, line 527, in currentThread IOError: (0, 'Error') Most of the top of the traceback isn't important. What I think is happening is that the print statement on line 527 of threading.py fails, because it is running detached from a console. This produces an IOError, and causes the Xron Dispatcher thread to terminate, and thus stops Xron from working until Zope is restarted. Suggested solutions: The obvious solution is to patch threading.py. This is not good for folks who want to use Xron on a hosting provider's server, where they may not be able to patch the python source. Zope could be made to ensure it provides a /dev/null sort of file for sys.stdout, if it is detached from the console. A workaround would be to use the STUPID_LOG_FILE (or whatever it is called now), as, if I remember correctly, it sends sys.stdout to a file. Xron could do something to ensure that sys.stdout goes somewhere before it calls Event.set(). Xron cannot just put a try: except: block around ScheduleChange.set(), because the call to set the Event would still not succeed. -- 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 )
