2009/8/25 Martijn Faassen <faassen@startifact.com>:
See my comment on naming. I think we should call 'zope.menu', 'zope.page', 'zope.resource'.
See my answer there :-)
* zope.ptresource - the page template resource that was moved into a separate package to make zope.browserresource independent from zope.pagetemplate. it's now a plugin for zope.browserresource - a custom resource factory, registered for "pt", "zpt" and "html" extensions.
Was it registered for these extensions already? In particular I'm wondering about the 'html' extension - I can see use cases to want to publish non-page template HTML files as static resources.
The DirectoryResource was creating page template resources for these extensions, so I just copied the behaviour. I also see the case when simple static HTMLs are needed, I think those cases are most, actually. But pagetemplate resources will work for non-templated HTMLs as well, and people can simply not include zope.ptresource configure.zcml and configure the resource factory for extensions they need. I guess most people won't even install zope.ptresource though, as it's not very useful. ZRT resources are more appropriate for dynamic css's and javascripts, so I think users will prefer it (BTW, it also needs to be adapted for new package).
Second, the "browser:defaultView" and "browser:defaultSkin" directives. The functionality of default views and default skins is currently contained in zope.publisher, and these directives only provide a way to configure default view/skin via ZCML. I think that these directives should be moved to zope.publisher as well, since it seems the right place for them and the move won't introduce extra dependencies for zope.publisher. zope.publisher indeed already depends, at least indirectly, on zope.configuration. It doesn't define any ZCML directives at this point though, which makes me a bit wary. Then again, zope.security does, and zope.publisher depends on it. So I think this is all right.
Okay, that's done :-)
Third, the "xmlrpc:view" directive and the XML-RPC method publisher. It's a nice thing, but people doesn't seem to be interested very much in XML-RPC these days. Also, it seems that zope.publisher will be refactored soon, so the future of xmlrpc modules is not clear. I see two options for this thing:
a) Extract it into the new, "zope.xmlrpc" module. b) Leave it there as is.
If noone demonstrates interest in discussing the xmlrpc, I'll probably choose option b :-)
Grok at least can't just lose its XML-RPC support, and we'd like to stop importing zope.app.publisher if we can. While I think most people have moved on to using other things than XML-RPC, I do think there's a lot of code out there that does use XML-RPC, and it's so convenient I suspect more code will be written in the foreseeable future.
I therefore would like to see a zope.xmlrpc module. I think there is code in other packages as well that could be moved in here. We do need to think about the import situation however.
That said, we shouldn't wait for this to be resolved to merge the other changes into the Zope Toolkit.
I'll leave it there for now, until XMLRPC and FTP refactorings. There's some PITA with functional tests for this module (or it's just me with not enough experience, whatever), so it'll take some time. I'd like other changes to be merged soon.
Finally, it'd be nice if we could give the new KGS system a workout by testing things with that. I hope you can involve Jim in this discussion. Then once we have a way of working figured out, it's important we also record this in the ZTK documentation.
Sorry, I also didn't catch up with the list recently, so I don't know about the "new KGS system" yet. :-) I'll read about it later. -- WBR, Dan Korostelev