[Zope-dev] Are input streams seekable in Zope?
Hi, I've stumbled over some code in Zope 2.7.0 that seems to suggest that input streams are meant to be seekable. In an extension I wrote for ZServer, i.e. AJPServer, I throw an exception when this is tried and I'm quite sure the call to seek wasn't there in 2.6.x. I found the call to seek in ZPublisher.HTTPRequest.py, line 128, in method retry. Does this mean that only seekable streams are allowed in ZPublisher (i.e. not stdin) or is this a bug? TIA, andreas ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [ZC] 1223/ 8 Reject Problem with meta_type
Gareth Bult wrote: Actually, this should be rejected. A Zope object without a meta_type has some pretty serious issues ;-) Interesting statement - not that I disagree .. but my question is - does a Zope that crashes when it could (with a one-line change) be made not to crash have *more* serious issues ? (I guess developers are going to say no, but I'm a user - I say yes !) your suggested one line change could have implications such as reduced data integrity and other unexpected behaviour. So, I'd say yes too, except your one-line change makes things worse ;-) fyi; Not that I'm saying it's a proper solution or one that should be implemented, but I've seen no ill effects in 5 months and around 3 million hits re; the suggested patch. (which for me is one up on repeated nasty site crashes .. ) *shrugs* I'd personally prefer to make the one line patch in the product that's missing a meta type in it's class definition ;-) Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Collector Status Meanings
Hi All, Apologies for the cross-posting, but I think this is relevent to all these lists. I've summarised the meaning of the various collector states here: http://dev.zope.org/CVS/CollectorStatuses Please let me know if you disagre with any of that, although I'm pretty sure they're right and will argue with anyone who thinks otherwise ;-) The only real change is that Deferred now means we asked the user for more information and we'll reject the issue unless they give it to us within a month I went through all the issues which WERE deferred and dealt with them. I'm trying to avoid having states where issues end up that aren't definitive and so get forgotten about. The wontfix stuff now has a definitve meaning, but it may still be good to go through them all once a year or so to check that none of them have been solved in other ways. I found quite a few of the deferred ones that really should have been wontfix had been addressed and could now be marked as resolved :-) cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Collector Status Meanings
I would put my $0.02 for a 'tested' state, entered from Resolved. So from resolved you could 'resubmit' back to pending or accepted, or go to tested. This because it does happen, that someone *thinks* they have fixed something, but didn't test it thoroughly (there are usually way to many combinations for one person to do so), and it wasn't really fixed. On Friday, July 30, 2004, at 10:01 AM, Chris Withers wrote: Hi All, Apologies for the cross-posting, but I think this is relevent to all these lists. I've summarised the meaning of the various collector states here: http://dev.zope.org/CVS/CollectorStatuses Please let me know if you disagre with any of that, although I'm pretty sure they're right and will argue with anyone who thinks otherwise ;-) The only real change is that Deferred now means we asked the user for more information and we'll reject the issue unless they give it to us within a month I went through all the issues which WERE deferred and dealt with them. I'm trying to avoid having states where issues end up that aren't definitive and so get forgotten about. The wontfix stuff now has a definitve meaning, but it may still be good to go through them all once a year or so to check that none of them have been solved in other ways. I found quite a few of the deferred ones that really should have been wontfix had been addressed and could now be marked as resolved :-) cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Zope-Coders] Collector Status Meanings
On Fri, 30 Jul 2004, Chris Withers wrote: Apologies for the cross-posting, but I think this is relevent to all these lists. I think this is a valuable discussion. I don't think cross-posted discussions work, though, so i'm replying in the various groups (except zope-collector-monitor, which is only meant for collector-originating submissions) with a followup to zope-coders. I've summarised the meaning of the various collector states here: http://dev.zope.org/CVS/CollectorStatuses Please let me know if you disagre with any of that, although I'm pretty sure they're right and will argue with anyone who thinks otherwise ;-) My intent for the states is different from what you suggested, in some cases significantly. It may be that the practice is more like you describe and makes more sense, i dunno, but here's what i intended: Pending: Issues that have not yet been settled or assigned to some supporter, and warrant attention. Your description, issues that haven't been considered, assumes that issues are always assigned or settled when they are examined, while i think some issues can remain in the pending state awaiting resource availability. Accepted: Issues that some supporter(s) has responsibility for resolving it, and it is not yet resolved. Your description says that some supporter has assessed the issue as warranting repair, and later says that the the issue has an assigned supporter. I think it's a lot clearer to directly say that an accepted issue has a supporter responsible for resolving it. Rejected: Issues that are settled as being somehow invalid or outside the scope of the system the collector serves. Resolved: Issues that are settled as having been solved. Deferred: Issues that are not assigned or settled but warrant revisiting at some later occasion. This enables, for instance, putting an issue aside until more information is collected. Wontfix: Issues that are settled as ones that won't be fixed. These issues are within the scope of the collector, but would require more effort than they're worth. (Sustained lack of a champion who will take responsibility for solving the issue is one sign of that.) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [Zope-Coders] Collector Status Meanings
On Fri, 30 Jul 2004 11:50:57 -0400 (EDT), Ken Manheimer [EMAIL PROTECTED] wrote: Accepted: Issues that some supporter(s) has responsibility for resolving it, and it is not yet resolved. Your description says that some supporter has assessed the issue as warranting repair, and later says that the the issue has an assigned supporter. I think it's a lot clearer to directly say that an accepted issue has a supporter responsible for resolving it. I don't think it makes sense to use this to indicate a supporter (and possibly some of their time) has been allocated to deal with the issue; the list of assigned supporters should be sufficient for that. If the list is empty, no supporter has been assigned. I think Accepted should be used to indicate that the issue is real and still needs to be addressed in some way. This is independent of assigning it to one or more specific supporters. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Zope Corporation ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [Zope-Coders] Collector Status Meanings
These definitions are how I've understood them since the inception of the collector. What I think Chris wants to do is to have a state that means pending rejection. He has defined deferred to mean this. I would prefer an explicit pending rejection state, FWIW. - C On Fri, 2004-07-30 at 11:50, Ken Manheimer wrote: On Fri, 30 Jul 2004, Chris Withers wrote: Apologies for the cross-posting, but I think this is relevent to all these lists. I think this is a valuable discussion. I don't think cross-posted discussions work, though, so i'm replying in the various groups (except zope-collector-monitor, which is only meant for collector-originating submissions) with a followup to zope-coders. I've summarised the meaning of the various collector states here: http://dev.zope.org/CVS/CollectorStatuses Please let me know if you disagre with any of that, although I'm pretty sure they're right and will argue with anyone who thinks otherwise ;-) My intent for the states is different from what you suggested, in some cases significantly. It may be that the practice is more like you describe and makes more sense, i dunno, but here's what i intended: Pending: Issues that have not yet been settled or assigned to some supporter, and warrant attention. Your description, issues that haven't been considered, assumes that issues are always assigned or settled when they are examined, while i think some issues can remain in the pending state awaiting resource availability. Accepted: Issues that some supporter(s) has responsibility for resolving it, and it is not yet resolved. Your description says that some supporter has assessed the issue as warranting repair, and later says that the the issue has an assigned supporter. I think it's a lot clearer to directly say that an accepted issue has a supporter responsible for resolving it. Rejected: Issues that are settled as being somehow invalid or outside the scope of the system the collector serves. Resolved: Issues that are settled as having been solved. Deferred: Issues that are not assigned or settled but warrant revisiting at some later occasion. This enables, for instance, putting an issue aside until more information is collected. Wontfix: Issues that are settled as ones that won't be fixed. These issues are within the scope of the collector, but would require more effort than they're worth. (Sustained lack of a champion who will take responsibility for solving the issue is one sign of that.) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Are input streams seekable in Zope?
Ames Andreas (MPA/DF) wrote: I've stumbled over some code in Zope 2.7.0 that seems to suggest that input streams are meant to be seekable. In an extension I wrote for ZServer, i.e. AJPServer, I throw an exception when this is tried and I'm quite sure the call to seek wasn't there in 2.6.x. I found the call to seek in ZPublisher.HTTPRequest.py, line 128, in method retry. Does this mean that only seekable streams are allowed in ZPublisher (i.e. not stdin) or is this a bug? When the object database raises a ConflictError, ZPublisher makes 3 attmpts (by default) to retry the request (in most cases, the request can succeed when retried). Is there a reason why the AJP protocol won't allow you to rewind to the beginning of the request stream? I don't think that the publisher does any other seek than to the start of the stream. Perhaps you need to derive an AJPRequest from HTTPRequest, and arrange not to need the 'stidn' stream during a retry; another possibility would be to submit a patch which allowed the retry mechanism to work without re-parsing the request stream (basically, the patch would need to clone the cgi.FieldRequest set from the original request into the one used for the retry). Tres. -- === Tres Seaver[EMAIL PROTECTED] Zope Corporation Zope Dealers http://www.zope.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Are input streams seekable in Zope?
Ames Andreas (MPA/DF) wrote at 2004-7-30 15:44 +0200: I've stumbled over some code in Zope 2.7.0 that seems to suggest that input streams are meant to be seekable. In an extension I wrote for ZServer, i.e. AJPServer, I throw an exception when this is tried and I'm quite sure the call to seek wasn't there in 2.6.x. I found the call to seek in ZPublisher.HTTPRequest.py, line 128, in method retry. Does this mean that only seekable streams are allowed in ZPublisher (i.e. not stdin) or is this a bug? ZServer usually streams the input stream via a temporary file. Therefore, ZPublisher can expect that its stdin is indeed seekable. As you found out, this is necessary when a request needs to be retried. -- Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [Zope-Coders] Collector Status Meanings
Ken Manheimer wrote at 2004-7-30 11:50 -0400: On Fri, 30 Jul 2004, Chris Withers wrote: ... My intent for the states is different from what you suggested, in some cases significantly. I like your intents! -- Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
