[Zope3-dev] zope.etree / zope.webdav
Hi, Long ago I rename zope.etree -> z3c.etree and zope.webdav -> z3c.dav to move it out of the zope namespace. At the time I seemed to have copied instead of moved the projects in subversion. I only released when Sidnei checked in change to zope.etree. I have just removed them. Aplogise to Sidnei again and to any one else you may have used / be using them. Please use the released z3c.etree or z3c.dav packages instead. Michael ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: WebDAV Future
Hi Roger, On Wednesday 25 April 2007 23:09:26 Roger Ineichen wrote: > > Subject: Re: [Zope3-dev] Re: WebDAV Future > > [...] > > > > zwebdavext.zopelocking, zwebdavext.zopefile - extensions > > > > This I like, but renaming zwebdavext -> zwebdavapp :-) This > > allows a clearer seperatation between the protocol components > > and the application components, which is what want now that I > > think about it. > > > > For example zwebdavext.zopefile isn't really an extension but > > more integration code for zwebdav and any application which > > uses zope.file. Then in the future I can hopefully get to > > work on zwebdav.dasl, zwebdav.acl etc. which are extensions > > to the protocol and hence should belong in zwebdav with more > > coresponding integration modules in zwebdavapp. > > Why this complex naming? I really like to see a namespace package > called z3c.webdav and use sub packages like: > > z3c.webdav.file > z3c.webdav.acl > > If this doesn't fit for distribution, buildout or eggs, > or other things I missed, why not: > > z3c.webdav > z3c.webdavfile > z3c.webdavacl > > But anyway that's up to you, I'm sure you will do it right and > I like your work anyway ;-) > > Sorry if I missed something, I didn't read all the full thread. I have playing with a few options over the last past few days including this option. z3c.webdav doesn't quite work the the fact that I want to support content / services from the z3c namespace, I would end up with package like z3c.webdav.z3cextfile, to distinush it say from z3c.webdav.zopefile. This doesn't quite sit right with me. But I am not going to split up this namespace as I previously suggested, as I do take your point that it does get complex. Thanks for the input, Michael ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: WebDAV Future
Hi Martijn, On Tuesday 24 April 2007 00:30:47 Martijn Faassen wrote: > Michael Kerrin wrote: > [snip] > [snip] > > You can almost do this, but now quite, as z3c.webdav is not a namespace > package in this plan (see below). > > > An other two options I can think of, instead of the naming convention > > above: > > > > 1. create a webdav namespace, webdaz (WebDAv for Zope), which would > > contain webdaz.core, webdaz.zopefile, webdaz.zopelocking etc > > It's nice that it's more flat. I think it's too easy to mistype 'webdaz' > for 'webdav', so -1 on this one from me. zwebdav would in fact have my > preference if you want to go this way. > Either name works for me so lets go for `zwebdav`. > > 2. Name the core webdav implementation z3c.webdav and then create eggs > > that are named like zope.file.webdav (for zope.file), > > zope.app.file.webdav, z3c.extfile.webdav, zope.locking.webdav etc. but > > which are separate from the underlying module. > > This won't work, as these packages themselves are not a namespace > package. As far as I'm aware, you can only create independently > installable eggs for subpackages of namespace packages (i.e. packages > without any code). Thanks, you just saved me from wasting a lot of time as this was original my favourite option. > > Does any one have any experience with this type of problem or does any > > one of a preference to which one they like best. Or is there other > > options that I have missed that is worth considering, in order for me to > > move this forward. > > Another option is to create a zwebdav or z3c.webdav package, and then > put a special namespace package in there meant for the extensions: > > zwebdav - core zope 3 webdav support > > zwebdav.ext - pure namespace package > > zwebdav.ext.zopefile, zwebdav.ext.zopelocking, etc. > > ToscaWidgets is an example of a package that does this. It has a > toscawidgets core, and then extensions are shipped as subpackages of the > toscawidgets.widgets namespace package. > > Yet another option would be to have a core package, and then extension > package in another namespace altogether: > > zwebdav - core webdav support > > zwebdavext.zopelocking, zwebdavext.zopefile - extensions This I like, but renaming zwebdavext -> zwebdavapp :-) This allows a clearer seperatation between the protocol components and the application components, which is what want now that I think about it. For example zwebdavext.zopefile isn't really an extension but more integration code for zwebdav and any application which uses zope.file. Then in the future I can hopefully get to work on zwebdav.dasl, zwebdav.acl etc. which are extensions to the protocol and hence should belong in zwebdav with more coresponding integration modules in zwebdavapp. > Grok does this. It has 'grok' as the core, and extensions are shipped as > 'megrok.five' and so on. > > Incidentally, we are thinking about splitting up grok into multiple > packages too. A difference with what you're talking about is that the > grok package will remain the same, but will start importing some of what > it needs from other packages which can be used independently. > > For that, we intend to do something like this: > > grok - package end users see, and depends on > >groklib (name still being pondered) - core grokker implementation > >grokcore.component - basic component architecture support for grok >grokcore.formlib - formlib support for grok > > > etc. The grokcore packages would have dependencies on groklib as well as > various Zope 3 packages (such as zope.component). Some of them may also > build on each other. groklib wouldn't have any dependencies (or almost > none). grok would depend on everything. Not very relevant to your > problem, but thought I'd show yet another example of package > organization. :) Thanks, Michael ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] WebDAV Future
Hi All, I want to move the webdav implementation on by releasing it to cheeseshop, supporting more content types and then working on some more interesting aspects of the protocol itself, and maybe even supporting other applications like Plone if there is interest. First I need to rename it out of the zope namespace, which was a mistake on my part in calling it this. But this brings up some packaging issues for me that I am not sure how best to do this in a consistent fashion that I can build on. Hence why I have delayed doing anything about this. Currently everything is in zope.webdav. Which includes support for the zope.app.file & zope.app.folder content types. Using zope.locking as a locking mechanism and using zope.copypastemove for copying and moving content. Each of the packages just mentioned should be optional (but aren't because of the current setup, which I want to fix). Now into future. I want to split this up into a core Zope3 WebDAV implementation, which will handle registering the different WebDAV methods, their implementation, declaring properties, exception handing which I could call z3c.webdav. This module / egg on it own will be pretty useless, as it doesn't know about any of the content or services in Zope3. Then I want for each content type and services in Zope its own egg so to speak, for example z3c.webdav.zopeappfolder, z3c.webdav.zopeappfile, z3c.webdav.zopefile, z3c.webdav.zopelocking. A lot of these extra eggs will be small and easy to write, and as more content types are supported by Zope3 I would like more webdav modules to be written for them. An other two options I can think of, instead of the naming convention above: 1. create a webdav namespace, webdaz (WebDAv for Zope), which would contain webdaz.core, webdaz.zopefile, webdaz.zopelocking etc 2. Name the core webdav implementation z3c.webdav and then create eggs that are named like zope.file.webdav (for zope.file), zope.app.file.webdav, z3c.extfile.webdav, zope.locking.webdav etc. but which are separate from the underlying module. Does any one have any experience with this type of problem or does any one of a preference to which one they like best. Or is there other options that I have missed that is worth considering, in order for me to move this forward. Thanks, Michael P.S. after writing all this down my preference is moving towards the last zope.file.webdav, etc. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Correctly sending ObjectModifiedEvents [was SVN: zope.webdav/trunk/src/zope/webdav/ Emit an ObjectModifiedEvent on successfully modifying a property with]
Philipp von Weitershausen wrote: Michael Kerrin wrote: Log message for revision 72694: Emit an ObjectModifiedEvent on successfully modifying a property with the proppatch method. ... +if changed: +zope.event.notify(ObjectModifiedEvent(self.context)) + Just emitting an ObjectModifiedEvent like that is pretty useless, IMO. With this you have no clue - whether the object or the object's annotations were modified - which properties of which schema were modified. The good news is that the ObjectModifiedEvent API actually supports this kind of stuff, you just need to use it: info = Attributes(ITheSchema, 'foo', 'bar', 'blergh') notify(ObjectModifiedEvent(obj, info)) (Attributes is importable from zope.lifecycleevent). Note that the object must not necessarily provide ITheSchema, it could also be that the ITheSchema(obj) adapter was changed (this is useful when sending modified events for annotation adapters like IZopeDublinCore). Very interesting - I never even knew you could do this :-) All modifications made by the PROPPATCH will be done via the adapter lookup you just mentioned so it is really nice that this is supported. Unfortunately, not many places in Zope 3 itself are good examples of this. In fact, not even formlib sends this extra information along with the events, something I've been meaning to report and fix. (Thanks for reminding me to do so :)). Thanks for the tip, I will definitely update webdav to use it. Michael ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Zope 3.3.1
On Tuesday 13 February 2007 10:00, Philipp von Weitershausen wrote: > On 13 Feb 2007, at 00:20 , Michael Kerrin wrote: > > On Monday 12 February 2007 10:41, Philipp von Weitershausen wrote: [snip] > > > > I don't know what is going on with the tests on Windows. But I have > > just > > managed ( for the first time :-) ), to compile, start, and run all > > the tests > > successfully on Windows. > > So, you're not seeing a test failure then? No. > Adam, can you make the installer for 3.3.1 again, upload it (w/o > publishing it) so that we can try to reproduce it on our machines? Good idea - as my build of Zope probable can't be trusted - see below. > > Althoug I had a slight problem starting Zope because of > > ZODB.winlock not > > working but considering all the problems I ran into to get the damn > > thing to > > compile I put this down to my lack of experience with Windows. > > How did you compile Zope on Windows? I assume you used some version > of Visual Studio? with lots of fun:-) I compiled it with MinGW. I couldn't find Visual Studio 2003 and it refused to work with VS 2005. I also had to hack distutils to get around a problem where it couldn't find msvcr71 (???). So I am surprised I got this far to be honest. > >> We can't delay this maintenance release any further. It's bad enough > >> that a *release (!) branch* has been broken for such a long time w/o > >> having been fixed. > >> > >> If this isn't fixed soon, I'm going to advise to the maintainer of > >> the > >> 3.3.x line to back out the change that led to the test failure so > >> that > >> we can assure all of the Zope 3.3 users out there that we're indeed > >> fixing bugs and releasing the fixes. Zope 3.3.1 has tons of other > >> bugfixes that people out there are waiting for. > >> > >> I hope we won't have to resort to reverting the zope.app.twisted > >> change. > > > > The thing is I don't know what as changed in the twisted code. I > > recently > > updated Twisted on the trunk - but I didn't put this change onto > > the 3.3 > > branch. > > I see. Perhaps this is spurious then? -- Michael Kerrin 55 Fitzwilliam Sq., Dublin 2. Tel: 087 688 3894 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Zope 3.3.1
Hi Philipp, On Monday 12 February 2007 10:41, Philipp von Weitershausen wrote: > I'd like to release Zope 3.3.1 soon. The tests are passing on Linux and > Mac OS, apparently there's only a problem with zope.app.twisted on > Windows, afaik. Can we get this problem isolated, analyzed and fixed > asap, please? I don't know what is going on with the tests on Windows. But I have just managed ( for the first time :-) ), to compile, start, and run all the tests successfully on Windows. Althoug I had a slight problem starting Zope because of ZODB.winlock not working but considering all the problems I ran into to get the damn thing to compile I put this down to my lack of experience with Windows. > We can't delay this maintenance release any further. It's bad enough > that a *release (!) branch* has been broken for such a long time w/o > having been fixed. > > If this isn't fixed soon, I'm going to advise to the maintainer of the > 3.3.x line to back out the change that led to the test failure so that > we can assure all of the Zope 3.3 users out there that we're indeed > fixing bugs and releasing the fixes. Zope 3.3.1 has tons of other > bugfixes that people out there are waiting for. > > I hope we won't have to resort to reverting the zope.app.twisted change. The thing is I don't know what as changed in the twisted code. I recently updated Twisted on the trunk - but I didn't put this change onto the 3.3 branch. Michael -- Michael Kerrin 55 Fitzwilliam Sq., Dublin 2. Tel: 087 688 3894 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Zope 3.3.1
On Monday 15 January 2007 13:23, Philipp von Weitershausen wrote: > On 15 Jan 2007, at 11:02 , Adam Groszer wrote: > > Hello Philipp, > > > > .../repos/main/Zope3/branches/3.3 > > fails too on the same test. > > Buildbot seems to sleep these days. I ran into that with one of by > > fixes too. > > > > Monday, January 15, 2007, 10:37:52 AM, you wrote: > >> On 15 Jan 2007, at 09:47 , Groszer Adam wrote: > >>> Hello Philipp, > >>> > >>> I have one failure here: > >>>testPORTCannotConnect > >>> (zope.app.twisted.ftp.tests.test_zope_ftp.FTPServerPort > >>> DataConnectionTestCaes) > >>> What about that? ignore? > >> > >> Shrug. Not good. Does that happen with the Zope 3.3 branch checkout > >> as well? Why haven't we caught this problem earlier? > > Michael, can you say anything about that zope.app.twisted.ftp > failure? We'd really like to get a 3.3.1 release out. I just ran all the tests on the 3.3 branch and on the 3.3.1 tag and I am not seeing this problem. Adam - what platform are you running these tests on - Windows / Linux / Mac, and also do you have a traceback of some sort that I can look at? Another thing to try is running the twisted ftp tests like so (in the same directory as test.py file) ./trial.py twisted.test.test_ftp which should run the same test you reported but using the twisted trial test runner instead of the zope testrunner. I am just curious to see if you get the same problem here also - and if so then the traceback might be a bit more informative. Michael -- Michael Kerrin 55 Fitzwilliam Sq., Dublin 2. Tel: 087 688 3894 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Removing SSL/SSH-Keys from Skeleton
Hi Christian, On Monday 18 December 2006 21:32, Christian Theune wrote: > Michael Kerrin wrote: > > Suppose I could merge some of the changes that from that branch to get > > rid of ssh_* and sftp code which should be independent of any twisted > > upgrade. Then a SSL cleanup is also independent of an upgrade, come to > > think about it. > > Did you have any chance to look into this? I am doing this now. Really sorry about the delay. > I also guess that the twisted upgrade could be documented on the road > map for Zope 3.4 so everybody knows that this is currently happening and > maybe someone wants to join you. Want to put a short page in there? Good point, I will do this now. Thanks, Michael -- Michael Kerrin 55 Fitzwilliam Sq., Dublin 2. Tel: 087 688 3894 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Removing SSL/SSH-Keys from Skeleton
Jim Fulton wrote: On Dec 7, 2006, at 2:00 PM, Michael Kerrin wrote: Hi, Jim Fulton wrote: On Dec 7, 2006, at 2:58 AM, Christian Theune wrote: Hi, didn't we say at some point in time that we wanted to remove the SSH/SSL keys that we deliver by with Zope 3? In zopeskel/etc there are still server.pem and ssh_host_rsa_key as well as in the root of the trunk. Is there any reason not to remove them from there? Nope, and every reason to remove them. It would also be good for someone to check whether there are any tests for the SSL support. If not, I'd like to see that SW go too. As part of the Twisted upgrade that I still have to complete, I have removed all the ssh_* files along with the broken sftp code in the mkerrin-twisted-upgrade branch. I can also check the SSL support as part of this work too, I am just not sure when I will get this finished. It would be good to remove the key files from the trunk sooner rather than later, as well as any ssl code that we know we don't have tests for. Suppose I could merge some of the changes that from that branch to get rid of ssh_* and sftp code which should be independent of any twisted upgrade. Then a SSL cleanup is also independent of an upgrade, come to think about it. Michael ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Removing SSL/SSH-Keys from Skeleton
Hi, Jim Fulton wrote: On Dec 7, 2006, at 2:58 AM, Christian Theune wrote: Hi, didn't we say at some point in time that we wanted to remove the SSH/SSL keys that we deliver by with Zope 3? In zopeskel/etc there are still server.pem and ssh_host_rsa_key as well as in the root of the trunk. Is there any reason not to remove them from there? Nope, and every reason to remove them. It would also be good for someone to check whether there are any tests for the SSL support. If not, I'd like to see that SW go too. As part of the Twisted upgrade that I still have to complete, I have removed all the ssh_* files along with the broken sftp code in the mkerrin-twisted-upgrade branch. I can also check the SSL support as part of this work too, I am just not sure when I will get this finished. Michael ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Twisted Upgrade
Hi All, Jim brought up the issue on IRC that I have known about for a while now that Twisted in Zope3 really needs to be updated. There are few other related issues that need to be sorted out apart from getting Zope3 running and all its tests passing. So I propose: 1. SFTP - lets just rip this out - it doesn't work and I don't have the interest to carry this any further. 2. Tests. I added code to zope.app.twisted to make the Twisted trial tests run within the zope testrunner (these are needed to test the Twisted / Zope3 FTP integration). But in later versions of Twisted trial does run, without modification, in the zope testrunner. So I propose adding tests to zope.testing to make sure that this still is the case - as there is nothing more annoying then tests that always pass no matter what happens. This wouldn't change any functionality of zope.testing but will just be a few extra tests that get run only iff twisted is installed. 3. Don't use an external branch, but import a Twisted release into the Zope repository. This was brought up before by some one after the Twisted subversion server went down and the Zope buildbot failed. A while back I got Zope3 running with the Twisted trunk and the tests passing with some changes to Zope. So over the weekend I will plan to make a branch available with the goal of getting all the work done so far out there and to get on with the rest of the issues. Any other issues, questions on this topic? Michael ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [Zope3-checkins] SVN: Zope3/trunk/src/zope/publisher/http.py Fix the level 2 test failure in zope.app.twisted.tests.test_inputbuffering.
Hi Marius, On Monday 09 October 2006 20:13, Marius Gedminas wrote: > Log message for revision 70591: > Fix the level 2 test failure in > zope.app.twisted.tests.test_inputbuffering. > I have looked into this a long time but since at the time the problem only appeared in a Python patch so I dropped the issue. I then looked into this 1 / 2 weeks ago and then I remembered how painful this was. The issue, or part of the issue, is that the WSGI specification says that: The optional "size" argument to readline() is not supported, as it may be complex for server authors to implement, and is not often used in practice. I have managed to patch cgi.FieldStorage up with a work around which I sent to the web-sig mailing list and which I have finally got around to creating a new bug report for python after seeing your checkin - see http://sourceforge.net/tracker/index.php?func=detail&aid=1573931&group_id=5470&atid=105470 The sole response on web-sig mailing list was to change the WSGI specification. But I wonder how many other WSGI applications are effected by this. If it just Zope and Twisted then changing the specification should be ok, otherwise things could get very messy for WSGI. Michael -- Michael Kerrin 55 Fitzwilliam Sq., Dublin 2. Tel: 087 688 3894 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope.etree comments
On Friday 25 August 2006 18:10, Fred Drake wrote: > On 8/25/06, Michael Kerrin <[EMAIL PROTECTED]> wrote: > > What name should I use, I have seen a lot of talk on this but never > > really followed any of the threads to the end. If you say use X I will. I > > don't want to start another thread on this. > > I think the name is fine. There are packages under zope that don't > get checked out as core, too, so no need to change it. Ignore the > namespace packages arguments, those are decoys. > > > Exactly. If you need a feature that is only in lxml, just importing lxml > > is probable the right thing to do. > > Yes. > > I think a wrapper that understands what versions of ElementTree might > be available and that implement the basic ElementTree API makes sense. > With the introduction of xml.etree in Python 2.5, the number of > possible spellings goes up yet again. Moving all the import cruft to > a single place makes sense. > > I will note that Zope 3 doesn't even come close to being happy with > Python 2.5. I don't have time to work on that, and a number of > discussions are probably needed to work everything out. I should > start a wiki page with notes on what needs to change, but that's a > separate discussion. I tried running the Zope3 tests against python2.5 also. It didn't work out to well :-( But the my instance did seem to work to a point. It might be worth my time replacing the Python2.5 support I have with the cElementTree and droping Python2.5 until this stabilizes Michael -- Michael Kerrin 55 Fitzwilliam Sq., Dublin 2. Tel: 087 688 3894 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: Fwd: Re: [Zope3-dev] zope.etree comments
Sorry for the duplicate mails - it turns out I can send mail it is just terrible slow. Michael -- Michael Kerrin 55 Fitzwilliam Sq., Dublin 2. Tel: 087 688 3894 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Fwd: Re: [Zope3-dev] zope.etree comments
I am not a PyPy sprint in Limerick and get seem to send mail - so I will try again. Hi Martijn, On Friday 25 August 2006 16:33, Martijn Faassen wrote: > I just noticed the existence of zope.etree. Besides a minor comment on > its use of 'zope' as the namespace package, which I believe is generally > reserved for core components, I have the following more conceptual comment: What name should I use, I have seen a lot of talk on this but never really followed any of the threads to the end. If you (Martijn) say use X I will. I don't want to start another thread on this. > There are currently three implementations of the ElementTree API: > > ElementTree (original implementation in plain Python) > cElementTree (same API, faster, C-code) > lxml.etree (same API but vastly extended, faster, dependency on > libxml2 etc) > > The motivation of zope.etree appears to be to be able to swap out > ElementTree with lxml for performance reasons. While as the developer of > lxml the increased use of lxml makes me happy, I still wonder why this > choice was made. Glancing through the code I cannot find a reference to > cElementTree at all. I wonder why the choice wasn't made to simply swap > out with cElementTree instead? The only reason cElementTree isn't there is that I haven't installed cElementTree on my laptop yet. It should be trivial to add this in though. > After all, the reason to do this, as stated, is performance. > cElementTree has performance, is easier to install than lxml (as it > doesn't have dependencies), will ship with Python 2.5, and has the same > API as ElementTree itself. > > The main reason to use lxml over cElementTree is not performance > (sometimes it's faster, sometimes slower, depending on what you do) but > is extended features - lxml has a huge featureset. Some of these > features can of course also help with performance, but only if you use > them. > > More features cannot be the reason for zope.etree however, as the whole > point is to use lxml and ElementTree interchangably, right? Exactly. If you need a feature that is only in lxml, just importing lxml is probable the right thing to do. All the zope.etree code is also in zope.webdav (it still is, as I haven't removed it yet). I thought this part of zope.webdav was a good idea, and not particular to webdav so this morning I had some time to write a README and I decided to just upload it. My motivation, is not just performance, is that I like ElementTree API and I wanted to use it in zope.webdav. And I would also like to see zope.webdav has a replacemenet to zope.app.dav at some point in the future. So I had the problem to choice a ElementTree implementation so instead of choicing an implementation I wrote zope.etree which doesn't tie zope.webdav to any one implementation but lets the admins / developers choice which implementation they want to use. The admins, developers who use zope.etree are the ones who can quote performance, or what ever reason they want for their decision to use lxml or cElementTree or plain elementtree. or whatever implementation. I hope this answers your questions and I will try add cElementTree support over the weekend. Michael > Regards, > > Martijn > > > > ___________ > Zope3-dev mailing list > Zope3-dev@zope.org > Unsub: > http://mail.zope.org/mailman/options/zope3-dev/michael.kerrin%40openapp.biz -- Michael Kerrin 55 Fitzwilliam Sq., Dublin 2. Tel: 087 688 3894 --- -- Michael Kerrin 55 Fitzwilliam Sq., Dublin 2. Tel: 087 688 3894 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope.etree comments
Hi Martijn, On Friday 25 August 2006 16:33, Martijn Faassen wrote: > I just noticed the existence of zope.etree. Besides a minor comment on > its use of 'zope' as the namespace package, which I believe is generally > reserved for core components, I have the following more conceptual comment: What name should I use, I have seen a lot of talk on this but never really followed any of the threads to the end. If you say use X I will. I don't want to start another thread on this. > There are currently three implementations of the ElementTree API: > > ElementTree (original implementation in plain Python) > cElementTree (same API, faster, C-code) > lxml.etree (same API but vastly extended, faster, dependency on > libxml2 etc) > > The motivation of zope.etree appears to be to be able to swap out > ElementTree with lxml for performance reasons. While as the developer of > lxml the increased use of lxml makes me happy, I still wonder why this > choice was made. Glancing through the code I cannot find a reference to > cElementTree at all. I wonder why the choice wasn't made to simply swap > out with cElementTree instead? The only reason cElementTree isn't there is that I haven't installed cElementTree on my laptop yet. It should be trivial to add this in though. > After all, the reason to do this, as stated, is performance. > cElementTree has performance, is easier to install than lxml (as it > doesn't have dependencies), will ship with Python 2.5, and has the same > API as ElementTree itself. > > The main reason to use lxml over cElementTree is not performance > (sometimes it's faster, sometimes slower, depending on what you do) but > is extended features - lxml has a huge featureset. Some of these > features can of course also help with performance, but only if you use > them. > > More features cannot be the reason for zope.etree however, as the whole > point is to use lxml and ElementTree interchangably, right? Exactly. If you need a feature that is only in lxml, just importing lxml is probable the right thing to do. All the zope.etree code is also in zope.webdav (it still is, has I haven't removed it yet). I thought this part of zope.webdav was a good idea, and not particular to webdav so this morning I had some time to write a README and I decided to just upload it. My motivation, is not just performance, is that I like ElementTree API and I wanted to use it in zope.webdav. And I would also like to see zope.webdav has a replacemenet to zope.app.dav at some point in the future. So I had the problem to choice a ElementTree implementation so instead of choicing an implementation I wrote zope.etree which doesn't tie zope.webdav to any one implementation but lets the admins / developers choice which implementation they want to use. The admins, developers who use zope.etree are the ones who can quote performance, or what ever reason they want for their decision to use lxml or cElementTree or plain elementtree. or whatever implementation. I hope this answers your questions and I will try add cElementTree support over the weekend. Michael > Regards, > > Martijn > > > > _______ > Zope3-dev mailing list > Zope3-dev@zope.org > Unsub: > http://mail.zope.org/mailman/options/zope3-dev/michael.kerrin%40openapp.biz -- Michael Kerrin 55 Fitzwilliam Sq., Dublin 2. Tel: 087 688 3894 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] zope.webdav
I have just added a new implemation of WebDAV to svn.zope.org for people to play with. Has I said in the checkin message - it contains support for all WebDAV methods including LOCK and UNLOCK, and all the properites defined in draft-ietf-webdav-rfc2518bis-15.txt. It also contains a new mechanism for specifing the properties defined on a resource. I never tested it on anything but linux (with only the konqueror and cadaver clients at that) so any news on how it fairs on anything else is much appreciated for those who do try to use it. Have fun, Michael -- Michael Kerrin 55 Fitzwilliam Sq., Dublin 2. Tel: 087 688 3894 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Was WebDAV locking implemented?
Hi Jim, no - don't think I implemented it anyways. The current status of my work on webdav is that I took 2+ months break from it, came back and decided to rewrite the namespace management has I was never completely happy with it. This part is turning out really difficult to get right. This has extended to other areas of the code has it is in my branch, so in a nutshell you could say that I have gone and started from strach :-) It is getting back to a resonable state, just one more big problem in handling errors to get over, then I will attack the locking problem. I am going to finish this - just when I don't know. Michael On Friday 16 June 2006 16:37, Jim Fulton wrote: > ? > > Jim > > -- > Jim Fultonmailto:[EMAIL PROTECTED]Python > Powered! > CTO (540) 361-1714 > http://www.python.org > Zope Corporation http://www.zope.com http://www.zope.org > > > > ___ > Zope3-dev mailing list > Zope3-dev@zope.org > Unsub: > http://mail.zope.org/mailman/options/zope3-dev/michael.kerrin%40openapp.biz -- Michael Kerrin 55 Fitzwilliam Sq., Dublin 2. Tel: 087 688 3894 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: SVN: Zope3/trunk/ Merge bug fixes to the FTP server from the mkerrin-remove_trial_tests
Hi Philip, On Tuesday 04 April 2006 17:25, Philipp von Weitershausen wrote: > Michael Kerrin wrote: > > Modified: Zope3/trunk/test.py > > === > > --- Zope3/trunk/test.py 2006-04-04 08:46:11 UTC (rev 66372) > > +++ Zope3/trunk/test.py 2006-04-04 10:02:50 UTC (rev 66373) > > @@ -57,6 +57,9 @@ > > # Get rid of twisted.conch.ssh warning > > warnings.filterwarnings( > > 'ignore', 'PyCrypto', RuntimeWarning, 'twisted[.]conch[.]ssh') > > +warnings.filterwarnings( > > +'ignore', '', DeprecationWarning, > > +'(zope[.]app[.]twisted[.]ftp|twisted[.]test[.]test_ftp)') > > > > result = testrunner.run(defaults) > > Michael, > > this last filter seems to ignore more than you really want. I'm curious, > which DeprecationWarnings are you trying to ignore anyways. I couldn't > find any in zope.app.twisted.ftp or twisted.test.test_ftp... I just released that during development I tried using the Twisted trunk to see if it would make my life any easier and this generated a whole bunch of DeprecationWarnings when you ran the tests. Since then I just assumed I was generating a bunch of DeprecationWarnings, which obviously I not. I will remove it later today. Michael -- Michael Kerrin 55 Fitzwilliam Sq., Dublin 2. Tel: 087 688 3894 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: webdav locking (was Re: [Zope3-dev] Re: [Zope-dev] Two visions)
Hi Gary, On Wednesday 01 March 2006 15:33, Gary Poster wrote: > On Mar 1, 2006, at 10:13 AM, Michael Kerrin wrote: > > so it doesn't get to the locking tests (which will fail) but this > > is good > > thing to aim at :-) > > Hey Michael. What are you planning to do with the locking stuff? > I'd like to see zope.locking (http://svn.zope.org/zope.locking/) > used, rather than zope.app.locking. It learns from zope.app.locking > while also addressing some issues and adding some features. I don't > have time to do much about proposing it and integrating it, though. > Maybe I can squeeze in a bit next week or week after. Brillant - Locking is next on my hit list, and I am planing on using zope.locking to improve the current implementation. I have an issue with zope.locking on a collection with infinite depth but I am planing on ignoring this use case for the moment and get the rest of the locking working without any infinite depth support and like yourself I am going to quite busy over the next few weeks so it will probably be slow in coming. But I would appreciate what you think about this particular use case. Some background: The current webdav spec RFC2518 will hopefully be deprecated in the next few months. The new specification which has just in the last fortnight gone into last call stage of development, contains a near rewrite of the locking sections to make things easier (so they say), especially relating to the lock null resources and locks on collections. And I am aiming at implementing these features as it is what apache does and I get the impresion that the writers of the spec have clearly learned from past problems implementing this feature. But one thing the new spec goes into that zope.locking doesn't have (I don't think) is when you lock a collection with infinite depth. The new specification says that the collection and all the descendents objects are to locked against one lock token. The collection been locked is called the "lockroot" and all descendent objects are then indirectly locked against this lock token. The specification goes on to say that if an object is added to such a locked folder then it is also automatically indirectly locked against the same lock token has the folder. Any successful unlock operation on a locked object must also unlock all resources associated with this lock token. (Sorry I the previous paragraph isn't completely clear but section 6.1 and 7.4 of http://www.ietf.org/internet-drafts/draft-ietf-webdav-rfc2518bis-14.txt explains this feature a lot better if I didn't make sense) Any ideas on this?, is it feasible or not within zope.locking? > If Jim successfully gets zc.sharing open sourced today then we have > some zope.locking/zc.sharing integration that (as one integration > option for zope.locking tokens) can filter so that only people with > locks have edit privileges. It seems to work pretty well, but it's > also just one way to use the zope.locking tokens. As with > zope.app.locking, the "locks" themselves are purely advisory until > you put in some code to make them enforced somehow. Can't wait. > zope.locking can do exclusive lock tokens, shared lock tokens, freeze > tokens (effectively, no one gets the lock), and can also support > custom tokens if you need them. Cheers, Michael -- Michael Kerrin 55 Fitzwilliam Sq., Dublin 2. Tel: 087 688 3894 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [Zope-dev] Two visions
On Wednesday 01 March 2006 15:22, Sidnei da Silva wrote: > On Wed, Mar 01, 2006 at 03:13:29PM +0000, Michael Kerrin wrote: > | so it doesn't get to the locking tests (which will fail) but this is good > | thing to aim at :-) > > You can run it with '-k' (for 'keep going'). Cool - thanks for the hint [snip] 38. finish pass -> 27 tests were skipped. <- summary for `locks': of 12 tests run: 8 passed, 4 failed. 66.7% -> running `http': [snip] 3. finish pass <- summary for `http': of 4 tests run: 4 passed, 0 failed. 100.0% Could have been a lot worse :-) Michael -- Michael Kerrin 55 Fitzwilliam Sq., Dublin 2. Tel: 087 688 3894 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [Zope-dev] Two visions
On Wednesday 01 March 2006 14:52, Stephan Richter wrote:
> On Wednesday 01 March 2006 09:50, Michael Kerrin wrote:
> > > First hit:
> > > http://www.google.com/search?q=webdav+litmus+tests
> > >
> > > What you think about turning those into functional doctests?
> >
> > Never seen that before - found a bunch of bugs with it too :-)
>
> You ran it already?
Against my webdav branch I get the following:
-> running `basic':
13. mkcol_with_body... pass
14. finish pass
<- summary for `basic': of 15 tests run: 15 passed, 0 failed. 100.0%
[snip]
10. move_cleanup.. pass
11. finish pass
<- summary for `copymove': of 12 tests run: 12 passed, 0 failed. 100.0%
-> running `props':
0. init.. pass
[snip]
23. propget... FAIL (No value given for property {kappa}somename)
24. propcleanup... pass
25. finish pass
<- summary for `props': of 26 tests run: 16 passed, 10 failed. 61.5%
-> 10 warnings were issued.
See debug.log for network/debug traces.
make: *** [check] Error 1
so it doesn't get to the locking tests (which will fail) but this is good
thing to aim at :-)
Michael
--
Michael Kerrin
55 Fitzwilliam Sq.,
Dublin 2.
Tel: 087 688 3894
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [Zope-dev] Two visions
On Wednesday 01 March 2006 14:32, Sidnei da Silva wrote: > On Wed, Mar 01, 2006 at 09:29:05AM -0500, Stephan Richter wrote: > | On Wednesday 01 March 2006 09:24, Sidnei da Silva wrote: > | > | Except that Michael Kerrins recent WebDAV work will shaddow Zope 2's > | > | support. If I understand his improved implementation correctly, then > | > | it is very, very cool! > | > > | > Did you run the litmus tests against it? :) > | > | I don't know what that is, of course. :-) I think talking to Michael is > | the better choice here. :-) > > First hit: > http://www.google.com/search?q=webdav+litmus+tests > > What you think about turning those into functional doctests? Never seen that before - found a bunch of bugs with it too :-) Thanks for the link Michael -- Michael Kerrin 55 Fitzwilliam Sq., Dublin 2. Tel: 087 688 3894 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: FTP
Hi Roger, yipe - that's a bug in the FTP code I wrote. I will get that fixed asap. But if it causing an immediate problem for you just rename the path variable on line 136 to fromPath Michael On Friday 17 February 2006 10:25, Roger Ineichen wrote: > Hi Michael, > > are you the right person for asking about FTP? > > btw, > what is the state of FTP. Is there everything implemented or is it > still under development? > > I get a error if I rename a folder via FTP. > > rename name Traceback (most recent call last): > File "D:\projektCompiler\trunkWebDev\src\twisted\internet\posixbase.py", > line 214, in mainLoop > self.runUntilCurrent() > File "D:\projektCompiler\trunkWebDev\src\twisted\internet\base.py", line > 518, in runUntilCurrent > f(*a, **kw) > File "D:\projektCompiler\trunkWebDev\src\twisted\internet\defer.py", line > 251, in errback > self._startRunCallbacks(fail) > File "D:\projektCompiler\trunkWebDev\src\twisted\internet\defer.py", line > 294, in _startRunCallbacks > self._runCallbacks() > --- --- > File "D:\projektCompiler\trunkWebDev\src\twisted\internet\defer.py", line > 307, in _runCallbacks > self.result = callback(self.result, *args, **kw) > File "D:\projektCompiler\trunkWebDev\src\zope\app\twisted\ftp\ftp.py", > line 136, in failed > raise ftp.PermissionDeniedError(self._path(path)) > exceptions.NameError: global name 'path' is not defined > > I'm using the newest z3 trunk on windows and FTP Voyager. > > Regards > Roger Ineichen > _ > Projekt01 GmbH > www.projekt01.ch > Langackerstrasse 8 > 6330 Cham > phone +41 (0)41 781 01 78 > mobile+41 (0)79 340 52 32 > fax +41 (0)41 781 00 78 > email [EMAIL PROTECTED] > _ > END OF MESSAGE -- Michael Kerrin 55 Fitzwilliam Sq., Dublin 2. Tel: 087 688 3894 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Reducing the amount of ZCML directives
Hi Philipp, On Monday 13 February 2006 11:08, Philipp von Weitershausen wrote: > looking for your comments at > http://dev.zope.org/Zope3/ReducingTheAmountOfZCMLDirectives :) > > This is a "formal" follow-up on my blog post on ZCML a while back > (http://www.z3lab.org/sections/blogs/philipp-weitershausen/2005_12_14_zcml- >needs-to-do-less). I expect there will be more proposals in this direction, > this is just the beginning. It is also the easy part. I am + 1 for the proposed directives, but I am not necessarily in favour for all the potential directives you list so I will wait for a proposal on that to comment future. Also note that I have proposed on this list doing a big job on the WebDAV code base in which will deprecate the provideInterface directive. So I can handle this one since I am up to my eyeballs in this code anyways. Michael -- Michael Kerrin 55 Fitzwilliam Sq., Dublin 2. Tel: 087 688 3894 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] WebDAV
On Thursday 09 February 2006 11:06, Stephan Richter wrote: > On Wednesday 08 February 2006 16:18, Michael Kerrin wrote: > > WebDAV Interfaces, Widgets and Adapters > > > > > > http://www.zope.org/Members/mkerrin/WebDAVInterfacesWidgetsAndAdapters > > > > This defines changes that I see has crucial but which introduce nasty > > backwards compatibility problems. So it would be handy to know who has > > developed any custom extension to zope.app.dav be it a custom adapter to > > zope.app.dav.interfaces.IDAVSchema or who have developed a custom WebDAV > > namespace (these are the two likely areas for problems). I am hoping that > > this figure is small :-) > > Hi Michael, > > It is good to finally see a real technical discussion again. I hope Jim is > reading the list again. :-) :-) > I really like this proposal, since it fixes the WebDAV support to a state > where it should be. I honestly doubt that anyone has been using WebDAV > until now. Thus I would not worry about BBB at this point, but it is still > good that you are asking! Great - this is what I have being hoping for :-) Thanks Michael -- Michael Kerrin 55 Fitzwilliam Sq., Dublin 2. Tel: 087 688 3894 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] WebDAV
Hi Stephan, On Thursday 09 February 2006 11:20, Stephan Richter wrote: > On Wednesday 08 February 2006 16:18, Michael Kerrin wrote: > > WebDAV? Namespace Management > > > > http://www.zope.org/Members/mkerrin/WebDAVProposal/wikipage_view > > [snip] > this is also an excellent proposal. I really like it! I think with this and > the other proposal, the Zope 3 WebDAV story will look really good. > > The only outstanding problem is with the arbitrary namespace data that we > might receive. Have you thought about that already? I don't want to add > more work, so if you do not want to think about this, then just ignore the > question. :-) I haven't really thought about it until now but it should fit into the proposal, but I am hoping it goes something like this. I think I need to play with some test implementation just to make sure. PROPFIND and PROPPATCH will know if a property is dead or not, considering that they are responsible for finding the correct namespace utility, so they could ask for standard dead namespace management utility. This utility can then generate on the fly a dead WebDAV widget and probable a dead property field and then everything continues has normal. I hope :-) To be honest I was a bit caught up in all the WebDAV namespace / specs that I forgot about dead properties until sometime early this week. But I am confident that I can get something alone these lines working without to much trouble. Michael -- Michael Kerrin 55 Fitzwilliam Sq., Dublin 2. Tel: 087 688 3894 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] WebDAV
Hi All, I have being quite busy lately trying to improve WebDAV support for Zope3. To this end I have two proposals worth your consideration. I don't yet have access to the proposals area of zope.org but I have put them up in my home folder on zope.org for the time being. They are: WebDAV Interfaces, Widgets and Adapters http://www.zope.org/Members/mkerrin/WebDAVInterfacesWidgetsAndAdapters This defines changes that I see has crucial but which introduce nasty backwards compatibility problems. So it would be handy to know who has developed any custom extension to zope.app.dav be it a custom adapter to zope.app.dav.interfaces.IDAVSchema or who have developed a custom WebDAV namespace (these are the two likely areas for problems). I am hoping that this figure is small :-) WebDAV? Namespace Management http://www.zope.org/Members/mkerrin/WebDAVProposal/wikipage_view Here I define how, and why, I am planning to manage a WebDAV namespace. This includes how to find which properties are defined on a object, and what widget to use to display the property, and how to extend an already registered WebDAV namespace. My goal for all this has being to develop zope.app.dav to a point where it can handle all of the WebDAV protocol details according to the RFC2518 specification, while only requiring a minimal knowledge of WebDAV from developers who just wish to integrate WebDAV protocol into there application. Also I have being doing a lot of reading of specifications and by using these changes I hope to begin development of other WebDAV protocols once I have finished with the core WebDAV support. Hope you like it, and any improvements / comments will be most appreciated. Michael -- Michael Kerrin 55 Fitzwilliam Sq., Dublin 2. Tel: 087 688 3894 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope.app.twisted.ftp tests
Hi Jim, If you are happy to wait a few days more, before including these into buildbot, I will create a branch to get these tests back into the same zope testing framework. From what Andrew Bennetts said in his response, this is very possible but will probable require a update of Twisted to the trunk. But then we can do what we are doing now and just have svn:external pointing to a specific revision of the Twisted trunk. Michael On Sunday 29 January 2006 14:48, Jim Fulton wrote: > Michael Kerrin wrote: > > Hi All, > > > > I have just fixed issue #533 and it just reminded me that I have some > > test for the twisted ftp server written using the Twisted trial testing > > framework. > > > > The reason for this is that at the Neckar sprint I tried to write tests > > for the zope.app.twisted.ftp.ftp.ZopeFTPShell. This object can be thought > > of has middle ware between Twisted and Zope, in fact it lives more up in > > the Twisted server then in Zope. Has most of the methods in this class > > return Twisted deferred objects it was next to impossible to test these > > methods using the standard zope testing framework. > > Why is that? > > > All these tests are pretty much > > > > self contained i.e. even by removing zope.app.ftp the tests still pass > > and there are only 26 of them. > > > > I am thinking that it would be a good idea to include these tests as > > part of the buildbot process, just after all the standard zope tests have > > run. It means that if some one apart from myself has to make any changes > > to the zope.app.twisted.ftp module, they will learn pretty quickly if > > something has broken, or if the Twisted external is updated. > > > > I have no idea on how / who to ask for this. But to run the tests we > > just have to run in the same place has the standard zope tests: > > > > ./trial.py zope.app.twisted.ftp.test > > > > There is a --reporter argument to this trial program that can take one > > of the following values bwverbose, text, verbose, or summary to control > > the amount of output. > > > > I hope this isn't to difficult to add in. > > I'll look at adding this. > > Jim -- Michael Kerrin 55 Fitzwilliam Sq., Dublin 2. Tel: 087 688 3894 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope.app.twisted.ftp tests
On Monday 30 January 2006 02:23, Andrew Bennetts wrote: > On Sat, Jan 28, 2006 at 09:44:44PM +0000, Michael Kerrin wrote: > > Hi All, > > > > I have just fixed issue #533 and it just reminded me that I have some > > test for the twisted ftp server written using the Twisted trial testing > > framework. > > > > The reason for this is that at the Neckar sprint I tried to write tests > > for the zope.app.twisted.ftp.ftp.ZopeFTPShell. This object can be thought > > of has middle ware between Twisted and Zope, in fact it lives more up in > > the Twisted server then in Zope. Has most of the methods in this class > > return Twisted deferred objects it was next to impossible to test these > > methods using the standard zope testing framework. All these tests are > > pretty much self contained i.e. even by removing zope.app.ftp the tests > > still pass and there are only 26 of them. > > With sufficiently recent Twisted (possibly 2.1, but definitely SVN), it > should be possible to run these tests with the standard zope testing > framework. Trial is now unittest compatible enough that > twisted.trial.unittests.TestCases can be used in plain unittest.TestSuites, > and so forth. > Thanks for the information. I will definitely try and get this to work, instead of adding a new testing framework to buildbot. It was just remember back in September / October trying to test the integration of Twisted / Zope using the zope testing framework caused me a lot of grief, has Stephan will testify to. At the time I will admit to learning a lot so I could have being doing something wrong. Michael -- Michael Kerrin 55 Fitzwilliam Sq., Dublin 2. Tel: 087 688 3894 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] zope.app.twisted.ftp tests
Hi All, I have just fixed issue #533 and it just reminded me that I have some test for the twisted ftp server written using the Twisted trial testing framework. The reason for this is that at the Neckar sprint I tried to write tests for the zope.app.twisted.ftp.ftp.ZopeFTPShell. This object can be thought of has middle ware between Twisted and Zope, in fact it lives more up in the Twisted server then in Zope. Has most of the methods in this class return Twisted deferred objects it was next to impossible to test these methods using the standard zope testing framework. All these tests are pretty much self contained i.e. even by removing zope.app.ftp the tests still pass and there are only 26 of them. I am thinking that it would be a good idea to include these tests as part of the buildbot process, just after all the standard zope tests have run. It means that if some one apart from myself has to make any changes to the zope.app.twisted.ftp module, they will learn pretty quickly if something has broken, or if the Twisted external is updated. I have no idea on how / who to ask for this. But to run the tests we just have to run in the same place has the standard zope tests: ./trial.py zope.app.twisted.ftp.test There is a --reporter argument to this trial program that can take one of the following values bwverbose, text, verbose, or summary to control the amount of output. I hope this isn't to difficult to add in. Michael -- Michael Kerrin 55 Fitzwilliam Sq., Dublin 2. Tel: 087 688 3894 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope.app.http.put
On Tuesday 25 October 2005 12:16, Stephan Richter wrote:
> On Tuesday 25 October 2005 09:18, Michael Kerrin wrote:
> > There is some code in zope.app.http.put module that I would like to
> > remove since the code in question seems a bit extreme in my opinion, and
> > its breaking the twisted integration.
> >
> > In the default PUT handler we have the following:
> >
> > for name in request:
> > if name.startswith('HTTP_CONTENT_'):
> > # Unimplemented content header
> > request.response.setStatus(501)
> > return ''
> >
> > Low and behold Twisted actually sets the HTTP_CONTENT_LENGTH variable
> > in the request and hence we always get a 501 response for a PUT request.
> >
> > I can't see the logic to failing a request like this, so is alright for
> > me to remove this code.
>
> If there is no unit test explaining the reason for this condition, please
> feel free to remove it. It is very important for SchoolTool that PUT works.
>
> Please add a test explaining why we not want this. :-)this.
There is a test in zope.app.http.put.tests.test_put to make sure that this
behavior is followed but it doesn't explain why you want to do this.
So I can remove the code and modify the test to make sure things go through
with a HTTP_CONTENT_ header.
Michael
--
Michael Kerrin
55 Fitzwilliam Square,
Dublin 2.
Tel: 353 (0) 87 688 3894
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] zope.app.http.put
Hi All,
There is some code in zope.app.http.put module that I would like to remove
since the code in question seems a bit extreme in my opinion, and its
breaking the twisted integration.
In the default PUT handler we have the following:
for name in request:
if name.startswith('HTTP_CONTENT_'):
# Unimplemented content header
request.response.setStatus(501)
return ''
Low and behold Twisted actually sets the HTTP_CONTENT_LENGTH variable in the
request and hence we always get a 501 response for a PUT request.
I can't see the logic to failing a request like this, so is alright for me
to remove this code.
Thanks
Michael
--
Michael Kerrin
55 Fitzwilliam Square,
Dublin 2.
Tel: 353 (0) 87 688 3894
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] zope.app.ftp, security, adapters
Hi All, I am having a problem with permissions and security in zope.app.ftp The writable method in FTPView basically uses adapter lookup on IWriteFile and tests this adapter if it has a 'write' attribute in order to test if a user can write to the specified file. The problem is this seems to be always true (assuming the user has permission to list the names in the directory otherwise an Unauthorized exception is thrown, (this is my next problem to fix). The adapter configuration for IWriteFile in zope.app.file has the permission of zope.ManageContent on it. But has far has I can see this permission is only tested if, in this case the write method, is called. So how do I get this writable method to work correctly, by reimplementing it or via some ZCML trick that I am unaware of. Thanks Michael Kerrin 55 Fitzwilliam Square, Dublin 2 Ireland Tel: 353 (0) 87 688 3894 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Zope3 trunk degenerating on Windows
Hi Tim, On Tuesday 11 October 2005 17:31, Tim Peters wrote: > [Michael Kerrin] > > > I have just seen a check in on Twisted from James Knight which should fix > > fcntl import problem in twisted.web2.channel.cgi > > > > I have also being in contact with Itamar Shtull-Trauring from the Twisted > > community and he said we found an import problem on the > > twisted.web2.channel.cgi module and the parts we care about in > > twisted.web2 should work fine (on windows) once this problem is fixed. > > > > I hope to be able to get hold of a Windows box later today just to run a > > few tests but that won't be until 7/8 tonight (11am local time now). > > Thank you for following up! I don't have experience with Twisted, so > don't know what to try. If you can point me at a patchset, happy to > try it on Windows any time. AFAICT, the Twisted-related failures were > the only ones remaining on Windows when I left off yesterday. I have just changed the svn:external for Twisted to a more stable 2.1 branch which should contain the fix for the Windows problem you reported. I still haven't checked Zope on windows yet because of a problem in the with FTP but I have being assured that it will run. I will check the buildbot link you sent in the morning and see what the status is then, fingers crossed. Michael ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope3 trunk degenerating on Windows
Hi Tim, On Monday 10 October 2005 19:08, Tim Peters wrote: > [Tim Peters] > > > I'll attach a (long) list of current errors. Most seem related to > > twisted, and may ultimately stem from that there is no fcntl module on > > Windows. > > Still true. I have just seen a check in on Twisted from James Knight which should fix fcntl import problem in twisted.web2.channel.cgi I have also being in contact with Itamar Shtull-Trauring from the Twisted community and he said we found an import problem on the twisted.web2.channel.cgi module and the parts we care about in twisted.web2 should work fine (on windows) once this problem is fixed. I hope to be able to get hold of a Windows box later today just to run a few tests but that won't be until 7/8 tonight (11am local time now). Michael ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Zope3 trunk degenerating on Windows
Hi Tim, On Monday 10 October 2005 14:28, Tim Peters wrote: > I'll attach a (long) list of current errors. Ah no! > Most seem related to > twisted, and may ultimately stem from that there is no fcntl module on > Windows. Agreed - I am assuming then from looknig at the trace back that Zope is not starting because of this. I don't have a Windows box handy to run this myself. I have just created a bug report for the Twisted guys at http://twistedmatrix.com/bugs/issue1270 and I am about to ask them about another problems we should be ware off about running twisted on windows. > The buildbot hasn't been of any help here, since the Windows box has > failed during its initial svn step non-stop since last Friday: > > http://buildbot.zope.org/ (Nice - I didn't know about this) > where every run on "Windows 2000 fred-win" dies in its checkout step with > > Failure: exceptions.AttributeError: ShellCommand instance has no > attribute 'commandFailed' This seems to be buildbot itself. > The > > Failure in test doctest_RecordingProtocol (zope.app.recorder.tests) > > looks unrelated to twisted; I'll take a look. OK. > The profiling.txt failure is (still) due to using a Windows-buggy > snapshot of zope.testing. > > I see the "new" functional-test warning > > RuntimeWarning: PyCrypto not installed, but continuing anyways! > > on Linux too. Is installing PyCrypto now a prerequisite for Zope3? PyCrypto is required if you want to run HTTP over SSL. If you don't want to do this then this can be safely ignored. Michael ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope fails to start
This has just being fixed. Just run 'svn up' in your z3 directory and Zope
should then start.
Michael
On Monday 10 October 2005 11:25, Andreas Reuleaux wrote:
> A clean checkout of zope3 from svn (revision 39029)
> fails to start
>
> I am using Python2.4 (as seems the default in the Makefile
> now) on Debian Sarge.
>
> $ svn co svn://svn.zope.org/repos/main/Zope3/trunk z3
> $ cd z3
> $ make
> ...
> cp sample_principals.zcml principals.zcml
> (some small changes in principals.zcml)
>
> And then:
>
> [EMAIL PROTECTED](~/z3)$ ./bin/runzope
> Traceback (most recent call last):
> File "z3.py", line 63, in ?
> run()
> File "z3.py", line 59, in run
> main(argv[1:])
> File "/home/reuleaux/z3/src/zope/app/twisted/main.py", line 68, in main
> service = setup(load_options(args))
> File "/home/reuleaux/z3/src/zope/app/twisted/main.py", line 114, in setup
> features=('twisted',))
> File "/home/reuleaux/z3/src/zope/app/appsetup/appsetup.py", line 114, in
> config context = xmlconfig.file(file, context=context, execute=execute)
> File "/home/reuleaux/z3/src/zope/configuration/xmlconfig.py", line 553, in
> file include(context, name, package)
> File "/home/reuleaux/z3/src/zope/configuration/xmlconfig.py", line 489,
> in include processxmlfile(f, context)
> File "/home/reuleaux/z3/src/zope/configuration/xmlconfig.py", line 344,
> in processxmlfile parser.parse(src)
> File "/usr/lib/python2.4/site-packages/_xmlplus/sax/expatreader.py", line
> 109, in parse xmlreader.IncrementalParser.parse(self, source)
> File "/usr/lib/python2.4/site-packages/_xmlplus/sax/xmlreader.py", line
> 123, in parse self.feed(buffer)
> File "/usr/lib/python2.4/site-packages/_xmlplus/sax/expatreader.py", line
> 216, in feed self._parser.Parse(data, isFinal)
> File "/usr/lib/python2.4/site-packages/_xmlplus/sax/expatreader.py", line
> 364, in end_element_ns self._cont_handler.endElementNS(pair, None)
> File "/home/reuleaux/z3/src/zope/configuration/xmlconfig.py", line 325,
> in endElementNS self.context.end()
> File "/home/reuleaux/z3/src/zope/configuration/config.py", line 553, in
> end self.stack.pop().finish()
> File "/home/reuleaux/z3/src/zope/configuration/config.py", line 699, in
> finish actions = self.handler(context, **args)
> File "/home/reuleaux/z3/src/zope/configuration/xmlconfig.py", line 489,
> in include processxmlfile(f, context)
> File "/home/reuleaux/z3/src/zope/configuration/xmlconfig.py", line 344,
> in processxmlfile parser.parse(src)
> File "/usr/lib/python2.4/site-packages/_xmlplus/sax/expatreader.py", line
> 109, in parse xmlreader.IncrementalParser.parse(self, source)
> File "/usr/lib/python2.4/site-packages/_xmlplus/sax/xmlreader.py", line
> 123, in parse self.feed(buffer)
> File "/usr/lib/python2.4/site-packages/_xmlplus/sax/expatreader.py", line
> 216, in feed self._parser.Parse(data, isFinal)
> File "/usr/lib/python2.4/site-packages/_xmlplus/sax/expatreader.py", line
> 364, in end_element_ns self._cont_handler.endElementNS(pair, None)
> File "/home/reuleaux/z3/src/zope/configuration/xmlconfig.py", line 325,
> in endElementNS self.context.end()
> File "/home/reuleaux/z3/src/zope/configuration/config.py", line 553, in
> end self.stack.pop().finish()
> File "/home/reuleaux/z3/src/zope/configuration/config.py", line 698, in
> finish args = toargs(context, *self.argdata)
> File "/home/reuleaux/z3/src/zope/configuration/config.py", line 1390, in
> toargs args[str(name)] = field.fromUnicode(s)
> File "/home/reuleaux/z3/src/zope/configuration/fields.py", line 141, in
> fromUnicode raise schema.ValidationError(v)
> zope.configuration.xmlconfig.ZopeXMLConfigurationError: File
> "/home/reuleaux/z3/site.zcml", line 7.2-7.68 ZopeXMLConfigurationError:
> File
> "/home/reuleaux/z3/zopeskel/etc/package-includes/buddydemo-configure.zcml",
> line 1.0-1.34 ConfigurationError: ('Invalid value for', 'package',
> "Couldn't import wikification, No module named wikification")
> ___
> Zope3-dev mailing list
> Zope3-dev@zope.org
> Unsub:
> http://mail.zope.org/mailman/options/zope3-dev/michael.kerrin%40openapp.biz
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] FTP Authentication
On Monday 18 April 2005 12:42, Jim Fulton wrote: > Michael Kerrin wrote: > > On Monday 18 April 2005 10:39, Jim Fulton wrote: > >>This is simply a result of the fact that no one has written a > >> credentials- extraction plugin for FTP yet. > > > > I wouldn't mind writing a credentials-extraction plugin for FTP which > > isn't that hard. But what I am confused about is the through the web > > configuration of the credentials plugins. > > > > How do I specify that an credentials-extraction plugin is for the FTP > > protocol and not for HTTP. > > You can't, other than including a clue in the name you register it with. > > This design represents a tradeoff. It is important (so I'm told ;) to > be able to have multiple extraction plugins of the same type that are > ordered. If it wasn't for the ordering requirement, we'd just use > adapters, which would be a bit simpler. If we stick with the ordering > requirement, then I think trying to provide a UI that allowed control > of ordering by type would be too confusing. > > (I'm sorely tempted to make an adapter-based credential plugin and make it > the default. It would simply adapt the request, largely avoiding the > plugin mechanism. Then people could use a different plugin if they > wanted finer control.) > > > Because the authenticate method loops through all the configured > > credentials plugins and calls the extractCredentials(request) method. > > Which is the method that throws the exceptions I mentioned in my previous > > email and hence my FTP plugin doesn't get called. > > Ah, I missed the bit about the exception. That's a bug in the session > plugin. If an extractor can't extract, it should return None. It > should be simple to repair the session extractor. Are you a contributor? :) I am not a contributor but I would like to help. This seems like a good place to start so I will give it a go later today and let you know if it is fixed. -- Michael Kerrin 55 Fitzwilliam Square, Dublin 2 Ireland Tel: 353 (0) 87 688 3894 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] FTP Authentication
On Monday 18 April 2005 10:39, Jim Fulton wrote: > > This is simply a result of the fact that no one has written a credentials- > extraction plugin for FTP yet. I wouldn't mind writing a credentials-extraction plugin for FTP which isn't that hard. But what I am confused about is the through the web configuration of the credentials plugins. How do I specify that an credentials-extraction plugin is for the FTP protocol and not for HTTP. Because the authenticate method loops through all the configured credentials plugins and calls the extractCredentials(request) method. Which is the method that throws the exceptions I mentioned in my previous email and hence my FTP plugin doesn't get called. -- Michael Kerrin 55 Fitzwilliam Square, Dublin 2 Ireland Tel: 353 (0) 87 688 3894 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] FTP Authentication
Hi, I have being playing with Twisted / Zope3 / FTP and I can not understand the ICredentialsPlugin plugins from zope.app.authentication and how it is configured. The major problem I see with them is that currently they are all HTTP based. So when I try and upload a file via FTP (with a username / password stored inside a PrincipalFolder) my user never gets authenticated and I can't upload the file. Worse yet the get the following errors. I get a "Could not adapt", zope.publisher.ftp.FTPRequest to zope.publisher.interfaces.http.IHTTPApplicationRequest when using the Session Credentials plugin. An AttributeError: 'tuple' object has no attribute lower when using the Zope Realm Basic-Auth plugin. And nothing seems to happen with No Challenge If Authenticated plugin. My ftp client just says Could not open file for writing: Can't write file. Note there is no problem authenticating users defined in the principals.zcml file. -- Michael Kerrin 55 Fitzwilliam Square, Dublin 2 Ireland Tel: 353 (0) 87 688 3894 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
