Re: [Framework-Team] Plone roadmap
On 21 October 2010 22:55, Chris Calloway c...@unc.edu wrote: On 10/6/2010 2:17 PM, Jon Stahl wrote: We already have mass upload, via collective.uploadify. We seem to have at least some work on mass download, via http://plone.org/products/zipfiletransport I'm sure both could use refinement. And search/replace-all TTW. http://plone.org/products/goreplace Seems like all of these could benefit from some attention/love/polishing/PLIPing. These are all add-on products, not Plone. Plone already does these things via WebDAV. Taking WebDAV away means taking this function out of Plone and having to install products to get the function back, which leads to pain when products stop getting attention/love/polishing as they do. And these kinds of things are core to content management, not really add-on behavior. I think the point was that *if* we decide to (have to?) drop WebDAV support, we'd need to integrate these products or something like them into Plone proper as a replacement for functionality we currently support in the core. Martin ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone roadmap
On Fri, Oct 22, 2010 at 12:07 AM, Martin Aspeli optilude+li...@gmail.com wrote: On 21 October 2010 22:55, Chris Calloway c...@unc.edu wrote: On 10/6/2010 2:17 PM, Jon Stahl wrote: We already have mass upload, via collective.uploadify. We seem to have at least some work on mass download, via http://plone.org/products/zipfiletransport I'm sure both could use refinement. And search/replace-all TTW. http://plone.org/products/goreplace Seems like all of these could benefit from some attention/love/polishing/PLIPing. These are all add-on products, not Plone. Plone already does these things via WebDAV. Taking WebDAV away means taking this function out of Plone and having to install products to get the function back, which leads to pain when products stop getting attention/love/polishing as they do. And these kinds of things are core to content management, not really add-on behavior. I think the point was that *if* we decide to (have to?) drop WebDAV support, we'd need to integrate these products or something like them into Plone proper as a replacement for functionality we currently support in the core. Exactly. :-) By PLIPing I meant writing a PLIP and doing the work necessary to polish these to the standard of quality necessary for inclusion in the core, if that is possible/superior to reimplementing from scratch. :jon ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone roadmap
On 10/6/2010 2:17 PM, Jon Stahl wrote: We already have mass upload, via collective.uploadify. We seem to have at least some work on mass download, via http://plone.org/products/zipfiletransport I'm sure both could use refinement. And search/replace-all TTW. http://plone.org/products/goreplace Seems like all of these could benefit from some attention/love/polishing/PLIPing. These are all add-on products, not Plone. Plone already does these things via WebDAV. Taking WebDAV away means taking this function out of Plone and having to install products to get the function back, which leads to pain when products stop getting attention/love/polishing as they do. And these kinds of things are core to content management, not really add-on behavior. -- Sincerely, Chris Calloway office: 3313 Venable Hall phone: (919) 599-3530 mail: Campus Box #3300, UNC-CH, Chapel Hill, NC 27599 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone roadmap
And mass upload/download:import/export of images/files/folders TTW. We already have mass upload, via collective.uploadify. If massuploading is supported through the core it should support support https, which is not true for collective.uploadify in all circumstances. -Tom -- My Book Plone 3 Multimedia ist available! http://amzn.to/dtrp0C Tom Gross email.@toms-projekte.de skype.tom_gross web.http://toms-projekte.de blog...http://blog.toms-projekte.de ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone roadmap
On 9/26/2010 11:42 PM, Alan Runyan wrote: Maybe think about killing WebDAV when we have these features: Offline editing, magical wysiwyg blobby editing controls. And mass upload/download:import/export of images/files/folders TTW. And search/replace-all TTW. -- Sincerely, Chris Calloway office: 332 Chapman Hall phone: (919) 599-3530 mail: Campus Box #3300, UNC-CH, Chapel Hill, NC 27599 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone roadmap
On Wed, Oct 6, 2010 at 8:34 AM, Chris Calloway c...@unc.edu wrote: On 9/26/2010 11:42 PM, Alan Runyan wrote: Maybe think about killing WebDAV when we have these features: Offline editing, magical wysiwyg blobby editing controls. And mass upload/download:import/export of images/files/folders TTW. We already have mass upload, via collective.uploadify. We seem to have at least some work on mass download, via http://plone.org/products/zipfiletransport I'm sure both could use refinement. And search/replace-all TTW. http://plone.org/products/goreplace Seems like all of these could benefit from some attention/love/polishing/PLIPing. :jon ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone roadmap
I don't think that's a good option. We may not need to support both, but supporting one is probably quite important. For one thing, it'd kill Enfold Desktop and similar integrations. WebDAV is also very useful for bulk movement of images and documents. Webdav is main mechanism for iPad to read/write blobs to remote servers. iWorks and GoodReader are both quite reasonable for doing day-to-day work on iPad. Yes, at this point I personally think it's fair to consider anything that isn't part of the web as dead to us. WebDAV is kinda part of the web. FTP, I agree - should not be supported. Besides, few people are willing to edit HTML by hand on the file system anymore, and people are increasingly moving away from blobby formats like .doc and are comfortable with doing editing through the web browser as long as we can supply proper formatting + layout support (via Deco) and a good autosave-to-draft implementation — and with the IndexedDB/localStorage options on the horizon for the web in the near future, we can even support offline editing in a proper, standards-based manner. Maybe think about killing WebDAV when we have these features: Offline editing, magical wysiwyg blobby editing controls. I've been pretty bullish on dropping WebDAV and FTP for a while now, and I think it's time to get serious about it. It siphons away our focus on proper, TTW solutions when there's always the you can use WebDAV for batch operations option that isn't really maintained by anyone — no disrespect to Enfold et al, of course, this is a client-side WebDAV issue that is unlikely to be particularly good in any OS, ever. I am totally fine with dropping WebDAV. It kinda works and is hard wired into zope/plone. So is FTP and xmlrpc. I think we should envision a future without WebDAV and FTP as core components of our stack. They never worked well in practice, and are unlikely to ever reach mainstream usage because of the extra steps, concept abstraction, and setup knowledge required. I think most people solely want files and folders wrt to WebDAV. Maybe constraining the problem is best. Not much to keep that story together. I do agree in 5 years WebDAV should be gone. The browser should be our only deployment target on the client side. I agree. I think we could even go as far as saying web browser is our only supported platform. While there are others they are not officially supported. Alan ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone roadmap
Just a note from the UI side of things here, since you're all doing a good job with the other bits: On Sun, Sep 5, 2010 at 11:10 AM, Hanno Schlichting ha...@hannosch.euwrote: On Sun, Sep 5, 2010 at 7:17 PM, Martin Aspeli optilude+li...@gmail.comoptilude%2bli...@gmail.com wrote: On 5 September 2010 15:29, Hanno Schlichting ha...@hannosch.eu wrote: This should get us out of the business of maintaining a web server, but will also likely mean the loss of FTP and WebDAV support. I don't think that's a good option. We may not need to support both, but supporting one is probably quite important. For one thing, it'd kill Enfold Desktop and similar integrations. WebDAV is also very useful for bulk movement of images and documents. I haven't ever seen an actual good and working WebDAV client for normal content editors. The WebDAV standard is dead and the big operating systems have no interest in fixing it or their implementations. FTP is even less user friendly and I've only seen WebFTP implementations that work for mortals. I think we should focus on better web-based upload and batch functionality and give up on those other protocols. As I said, there's some customers that want this, but it's a tiny minority and thus best served by an add-on. Just because FTP and WebDAV have been cool in 1998 doesn't mean we need to keep them in 2010. With HTML5 and AJAX UI's we have better answers to these use-cases now. Yes, at this point I personally think it's fair to consider anything that isn't part of the web as dead to us. In actual use, people are much more comfortable with doing everything through a web browser these days than they were in 1998, both because web browsers have become more capable, and because we have more and more users with less sophistication and capability to keep track of abstractions like a WebDAV/FTP representation of their content — it's bad enough in most systems that separate the admin interface from the actual content interface, adding another abstraction on top of this isn't going to work for the average content author. Besides, few people are willing to edit HTML by hand on the file system anymore, and people are increasingly moving away from blobby formats like .doc and are comfortable with doing editing through the web browser as long as we can supply proper formatting + layout support (via Deco) and a good autosave-to-draft implementation — and with the IndexedDB/localStorage options on the horizon for the web in the near future, we can even support offline editing in a proper, standards-based manner. I've been pretty bullish on dropping WebDAV and FTP for a while now, and I think it's time to get serious about it. It siphons away our focus on proper, TTW solutions when there's always the you can use WebDAV for batch operations option that isn't really maintained by anyone — no disrespect to Enfold et al, of course, this is a client-side WebDAV issue that is unlikely to be particularly good in any OS, ever. I think we should envision a future without WebDAV and FTP as core components of our stack. They never worked well in practice, and are unlikely to ever reach mainstream usage because of the extra steps, concept abstraction, and setup knowledge required. The browser should be our only deployment target on the client side. -- Alexander Limi · http://twitter.com/limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone roadmap
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alexander Limi wrote: I think we should envision a future without WebDAV and FTP as core components of our stack. They never worked well in practice, and are unlikely to ever reach mainstream usage because of the extra steps, concept abstraction, and setup knowledge required. +1 Robust support for uploading/download for multiple files through a ZIP archive is often good enough and can be handled by most users and in addition something like PloneFlashUpload for uploading multiple files in one run (I think HTML5 has some special support for doing this). - -aj -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQGUBAEBAgAGBQJMjaoVAAoJEADcfz7u4AZjk2sLv2y50LZcnAbcjAl8In5Jxabs 5R2p7Mk8BogdXKfFAzineFrIDlQwp+0u0jhoV3kEp7jwfsoZHxdB9bew9etxhnQP i+E4cCKhxPrAHtBaP2mbdRHztliOriJUgl/vk+9n6FpkyGPh1g8TDXLkR2JlaYEY b4Xql1ItMKfQxz7uu0MJk1tgTJLLDuBNbkpjRKiy9gdNdiH5msYElY8XIZkpzeqZ T31EVS/zQyHn0ClsDno+fV77IOfvcMxLo6zzl7Okmdpqf+K6KRINQim5fyE+vY+A CgFhtsiBAzkqWno8X+H6zf+CDdiZ3qVgdZn+R6xOR0kVTEPq+nfXgxY6qTEY4OvC 7oFDviIEZA9CwMtTnjpwVrx4NjAQnJKQmT7eoxMfjU0VM1TruCEmN8wirUnr5Bja 2Ucb1yfHq93O9VA3ux3u5yd/CUFfLhkE7cwd4B++XD5gAGfhdEM6YH2lKxB761Qn 1J/8xapAaPNEtOC/CsBmT7Bw8ekGlxg= =q8js -END PGP SIGNATURE- attachment: lists.vcf___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone roadmap
On 6 September 2010 03:01, Sidnei da Silva sidnei.da.si...@canonical.com wrote: If I'm allowed to get one suggestion in there: On Thu, Sep 2, 2010 at 3:39 PM, Laurence Rowe l...@lrowe.co.uk wrote: snip WSGI Various components should be move out of Plone and into the WSGI pipeline. This should allow us to share code with other projects. Prime contenders would be: * Authentication * Resource registries One thing I would like to see, and would likely be a small (though effective) improvement, specially for Plone would be: * Flushing the Document Early (as described by: http://www.stevesouders.com/blog/2009/05/18/flushing-the-document-early/) I *think* we should be able to get the whole (or most of the) head/head tag flushed out to the browser (maybe with Transfer-Encoding: chunked, by way of RESPONSE.write() or similar WSGI majik). If you think about it, for the great majority of Plone sites that part of the page is fairly static, except maybe for the title tag and some metadata. If we could get it far enough so that the browser starts fetching the CSS and JS resources while Plone does it's thing to render the rest of the page, it would be a great win already. I fear this would be difficult to implement. Before being able to flush we need to be sure of the HTTP status code and that no more headers need to be sent for example when would we know to send a 302 redirect to a login form. Does this work for traversal based systems? In the php example he cites, flushing before database calls is trivial to implement. By the point we were in a position to flush, would any time be saved or would most of the database loads (that cause the worst slowdowns) have occurred already? ZPT is slow, but Chameleon will bring significant improvements on template rendering time. Assuming we were able to flush, would it make any difference to rendering time if the resources were already cached on the browser? If resource parsing time is not significant here, ensuring landing pages are cached in a proxy seems a simpler solution. Laurence ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone roadmap
On 2010-9-5 17:29, Hanno Schlichting wrote: PluggableAuthService -- There's tons of code based on this. I imagine we can first move the authentication API's into a WSGI middleware querying PAS as the backend. This sounds like the mistake repoze.who 1 made. It turns out that for almost every use case you want more control over handling login behaviour than WSGI middleware can provide. It is much simpler to have a simple API to an AAA service and use that than to try pushing this into middleware. Wichert. -- Wichert Akkerman wich...@wiggy.net It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone roadmap
On Sun, Sep 5, 2010 at 5:46 PM, Wichert Akkerman wich...@wiggy.net wrote: On 2010-9-5 17:29, Hanno Schlichting wrote: PluggableAuthService -- There's tons of code based on this. I imagine we can first move the authentication API's into a WSGI middleware querying PAS as the backend. This sounds like the mistake repoze.who 1 made. It turns out that for almost every use case you want more control over handling login behaviour than WSGI middleware can provide. It is much simpler to have a simple API to an AAA service and use that than to try pushing this into middleware. Right, I'm aware of the repoze.who lessons. Authorization is always going to be a WSGI framework component (endware) and not an isolated middleware. But there should be some subpart of the API, which allows you to share the same authorization information across multiple WSGI applications. Or deal with some of the external authorization handling, when you offload things to Apache or other SSO approaches. But I'm not familiar enough with this topic to know what exact subpart this is. It might come down to just the userid. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone roadmap
On Sun, 2010-09-05 at 18:18 +0200, Hanno Schlichting wrote: On Sun, Sep 5, 2010 at 5:46 PM, Wichert Akkerman wich...@wiggy.net wrote: On 2010-9-5 17:29, Hanno Schlichting wrote: PluggableAuthService -- There's tons of code based on this. I imagine we can first move the authentication API's into a WSGI middleware querying PAS as the backend. This sounds like the mistake repoze.who 1 made. It turns out that for almost every use case you want more control over handling login behaviour than WSGI middleware can provide. It is much simpler to have a simple API to an AAA service and use that than to try pushing this into middleware. Right, I'm aware of the repoze.who lessons. Authorization is always going to be a WSGI framework component (endware) and not an isolated middleware. But there should be some subpart of the API, which allows you to share the same authorization information across multiple WSGI applications. Or deal with some of the external authorization handling, when you offload things to Apache or other SSO approaches. But I'm not familiar enough with this topic to know what exact subpart this is. It might come down to just the userid. r.who 2 actually allows you to dial responsibilities up and down. You can use full stack middleware that lends it effectively the same responsibilities as r.who 1, or you can use only the r.who API portion in an app or you can combine the two approaches as necessary. See also http://docs.repoze.org/who/2.0/narr.html#using-repoze-who-without-wsgi-middleware The particular pain point you should never run into, because it is truly horrible: don't try to do any login form post handling in an identifier. Just allow the application to render a self-posting login form and use the API to check credentials and set headers and so on, rather than putting the login form handling itself into middleware machinery. In particular, never do anything remotely like the RedirectingForm plugin within http://svn.repoze.org/repoze.who/trunk/repoze/who/plugins/form.py (it wants to be the target for a login form post). Aside from that (which is a problem for people of any competence level), most of the problems with the middleware approach stem from needing to explain how the middleware approach works to integrators of widely varying competence levels. Each has his own slightly varying requirements, and each needs the middleware approach to be explained to him within that context. This has been a truly painful task for me, but that's more an indictment of my level of patience than it is of r.who or things like it. - C ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone roadmap
On 5 September 2010 15:29, Hanno Schlichting ha...@hannosch.eu wrote: - With Zope 2.13 / Plone 4.1 we are cleaning up the query interface a bit. The catalog's search methods now all want a simple dictionary as the query specification and issue deprecation warnings for everything else. Can I ask why we need to do this? It seems like an obvious use case for keyword arguments, and this is a pattern we've been documenting and promoting for a long, long time. +1 to removing the REQUEST magic, though. Quite a bit of code will need to be updated to avoid using keyword arguments, passing in requests objects or mixtures of all of these. This will make it easier to switch to a different implementation later on, as we can keep the query syntax intact. We could do that with a query syntax based on kwargs as well, of course. ;-) We have also deprecated the insane empty query behavior of the catalog. So far any query which didn't result in any index restriction returned the entire catalog content. Starting in Zope 2.14 you get an empty result instead. +lots to this and everything else - Get a new plone.indexing package or extend plone.indexer to do the job of collective.indexing. Especially create indexing events which are managed by an index manager instead of relying on mix-in classes. This will replace object.reindexObject() and similar calls, CMF's CatalogAware and the various catalog multiplex solutions. This will need a rather long deprecation period as these calls are all over the place. They are all over the place, but rarely customised/subclassed, so one thing we can probably do is make some of these no-ops. - Once we have intid's we can change the internal unique id of the catalog from the physical path over to an intid. Perhaps we should consider using UUIDs instead of intids? - Once we have parent pointers we can probably ditch storing metadata in the catalog and load objects directly. Why do __parent__ pointers help here? The Publisher - The Zope2 publisher has become incredibly complex, with numerous different hooks. In the long run (Plone 6?) we should replace it with our own simplified publisher which runs only in a WSGI pipeline. There will be a lot to learn from BFG here, though that is probably too simplistic for Plone. Concrete things I'd like to see: - Get a new round of community experimentation with WSGI now that's inside Plone 4.1. We have seen some good interest while repoze.zope2 was new and shiny. +1 - the downfall of repoze.zope2 was that it kept drifting out of sync with Zope 2 and Plone. Hopefully wrap these things up and have Plone 4.2 come with an official documented WSGI story. If things go well we can make WSGI the only supported deployment option for Plone 5. This should get us out of the business of maintaining a web server, but will also likely mean the loss of FTP and WebDAV support. I don't think that's a good option. We may not need to support both, but supporting one is probably quite important. For one thing, it'd kill Enfold Desktop and similar integrations. WebDAV is also very useful for bulk movement of images and documents. Note that Dexterity has a pretty sane, pretty well documented WebDAV approach. I can't see why it has to be incompatible with WSGI. Very little of the DAV stuff is actually in the web server or publisher. Once we have a good TTW multi-upload functionality this becomes possible (even though some people will complain, but they will need to maintain and evolve the code on their own - it's a niche requirement best done as an add-on, much like CMIS will be for quite a while). TTW multi-upload certainly helps, but WebDAV has for a long time been our answer for desktop integration, and I think jettisoning it would be a shame. Multi-upload doesn't help you uploading a large folder tree with images or files, downloading the same, opening and saving from desktop apps, etc. - Experiment again with a cleaned up request/response object based on WebOb. There's some insanities like the support for both getattr and getitem to access request values, the whole DTML automagic quote behavior and a ton more. I think we can let Plone opt into a simple request object that doesn't support getattr and DTML quoting and various stupid variables (_steps anyone?). I think we have done some steps towards it, for example with supporting the standard dict API for accessing containers instead of objectIds and friends. If we can move the copy/cut/paste code over to a new approach we can avoid most of the manage_ hooks. Once we figure out a new pattern to do object construction (the new invokeFactory) things will get easier. You can use the ZTK createObject() method, which just looks up and calls an IFactory utility by name. This is what Dexterity does, and it's pretty straightforward. An IFactory is just a callable, so you can register a class object as an IFactory,
Re: [Framework-Team] Plone roadmap
On 5 September 2010 20:01, Laurence Rowe l...@lrowe.co.uk wrote: On 5 September 2010 19:17, Martin Aspeli optilude+li...@gmail.com wrote: On 5 September 2010 15:29, Hanno Schlichting ha...@hannosch.eu wrote: - Once we have intid's we can change the internal unique id of the catalog from the physical path over to an intid. Perhaps we should consider using UUIDs instead of intids? We want to use intids because it is more efficient to intersect sets of integers. They are only an implementation detail though, and it should be possible to zap and rebuild your catalogue (assigning different intids) without problems. - Once we have parent pointers we can probably ditch storing metadata in the catalog and load objects directly. Why do __parent__ pointers help here? With __parent__ pointers you can pull an object directly out of the ZODB complete with it's location context. That means fetching the title and description for an item is usually just an object load. What's not so clear about this is how we index an object's path and it's allowed roles and users for the view permission. We should be able to learn from Zope3 here though. Tthere are balances to be struck between read and write efficiency here. It's worth noting here that the overhead of constructing the full location chain from a content item to the application root is much cheaper following __parent__ pointers up than traversing down the hierarchy. At each level of traversing you load the content object itself and search the BTree for the child (loading several BTree objects). With __parent__ pointers you can directly load each parent. I think this means that we probably won't have to worry about providing a cached absolute url metadata lookup or even cached roles and users as metadata - as these will only be calculated for a page's worth of content items. We will of course need an index on allowed roles and users and probably a descendants index (which zc.relation might provide), though only for those particular 'sections' to which searches are restricted. Laurence ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone roadmap
Right, I'm aware of the repoze.who lessons. Authorization is always going to be a WSGI framework component (endware) and not an isolated middleware. But there should be some subpart of the API, which allows you to share the same authorization information across multiple WSGI applications. Or deal with some of the external authorization handling, when you offload things to Apache or other SSO approaches. But I'm not familiar enough with this topic to know what exact subpart this is. It might come down to just the userid. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team Realistically this is what Oauth[1] already does so that one doesn't need to concentrate on worrying about the intricacies of passing or sharing that information. PAS could use OAuth to pipe the required data back to Plone. Right now the Openid stuff is a step in the right direction but realistically it creates a virtual like user in Plone. This could possibly be extended whilst i'm doing work on my plip ticket with some prototypal code on how it would work. [1]: http://oauth.net/ -- Christopher Warner http://cwarner.kernelcode.com ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone roadmap
On Sun, 2010-09-05 at 19:49 +0200, Laurence Rowe wrote: On 5 September 2010 18:47, Chris McDonough chr...@plope.com wrote: On Sun, 2010-09-05 at 18:18 +0200, Hanno Schlichting wrote: On Sun, Sep 5, 2010 at 5:46 PM, Wichert Akkerman wich...@wiggy.net wrote: On 2010-9-5 17:29, Hanno Schlichting wrote: PluggableAuthService -- There's tons of code based on this. I imagine we can first move the authentication API's into a WSGI middleware querying PAS as the backend. This sounds like the mistake repoze.who 1 made. It turns out that for almost every use case you want more control over handling login behaviour than WSGI middleware can provide. It is much simpler to have a simple API to an AAA service and use that than to try pushing this into middleware. Right, I'm aware of the repoze.who lessons. Authorization is always going to be a WSGI framework component (endware) and not an isolated middleware. But there should be some subpart of the API, which allows you to share the same authorization information across multiple WSGI applications. Or deal with some of the external authorization handling, when you offload things to Apache or other SSO approaches. But I'm not familiar enough with this topic to know what exact subpart this is. It might come down to just the userid. r.who 2 actually allows you to dial responsibilities up and down. You can use full stack middleware that lends it effectively the same responsibilities as r.who 1, or you can use only the r.who API portion in an app or you can combine the two approaches as necessary. See also http://docs.repoze.org/who/2.0/narr.html#using-repoze-who-without-wsgi-middleware The particular pain point you should never run into, because it is truly horrible: don't try to do any login form post handling in an identifier. Just allow the application to render a self-posting login form and use the API to check credentials and set headers and so on, rather than putting the login form handling itself into middleware machinery. In particular, never do anything remotely like the RedirectingForm plugin within http://svn.repoze.org/repoze.who/trunk/repoze/who/plugins/form.py (it wants to be the target for a login form post). Aside from that (which is a problem for people of any competence level), most of the problems with the middleware approach stem from needing to explain how the middleware approach works to integrators of widely varying competence levels. Each has his own slightly varying requirements, and each needs the middleware approach to be explained to him within that context. This has been a truly painful task for me, but that's more an indictment of my level of patience than it is of r.who or things like it. I'm tempted to say that the login form should be a separate application end point to the CMS. Authentication is something that can and should be shared across multiple applications - it's much easier to maintain a number of smaller focussed applications than one large monolithic one. Dunno. Not really even sure what that means. We tried to get generality by putting a login form handler inside the r.who application, which arbitrary application code (another application) could post to. It failed because at the end of the day, login form integration for arbitrary customers requires a lot of control over the process from end to end; nobody is willing to give up any features (such as login logging, arbitrarily skinned login form, arbitrarily complex error messages, etc) to service the more general goal of cross-application login (especially when they only have one application anyway, understandably). - C ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone roadmap
If I'm allowed to get one suggestion in there: On Thu, Sep 2, 2010 at 3:39 PM, Laurence Rowe l...@lrowe.co.uk wrote: snip WSGI Various components should be move out of Plone and into the WSGI pipeline. This should allow us to share code with other projects. Prime contenders would be: * Authentication * Resource registries One thing I would like to see, and would likely be a small (though effective) improvement, specially for Plone would be: * Flushing the Document Early (as described by: http://www.stevesouders.com/blog/2009/05/18/flushing-the-document-early/) I *think* we should be able to get the whole (or most of the) head/head tag flushed out to the browser (maybe with Transfer-Encoding: chunked, by way of RESPONSE.write() or similar WSGI majik). If you think about it, for the great majority of Plone sites that part of the page is fairly static, except maybe for the title tag and some metadata. If we could get it far enough so that the browser starts fetching the CSS and JS resources while Plone does it's thing to render the rest of the page, it would be a great win already. -- Sidnei ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone roadmap
dev.plone.org tracker is currently unable to create tickets (gives some xml parsing error), so I'm posting this here: Registration form spam protection should be improved. Currently Plone 3.x sites (not sure about 4.x) are getting spammed by bots registering dumm users. There are two first line of defence methods I would like to propose: - honeypot: form would have additional css-hidden field that must be left empty on submission (raises validation error and message if not) - optional javascript only form submission Cheers, Domen On Fri, 2010-09-03 at 15:29 +0100, Martin Aspeli wrote: Hi, On 3 September 2010 15:18, Laurence Rowe l...@lrowe.co.uk wrote: On 2 September 2010 22:16, Martin Aspeli optilude+li...@gmail.com wrote: Hi Laurence, +1 to everything here. Other big things for me: - I think we want Deco GUI + Blocks rendering as an optional add-on for Plone 4.x at some point, to get this tested properly. We certainly want more people to start using it and use it for customer projects. It does represent an invasive and radical change from the status quo, so it is much more of a risk to include in 4.x as a supported add-on than Dexterity for instance. It's certainly something we need to talk about more. (And in response to Roel, I'll certainly be at the conference and keen to talk about it there.) I don't think we should say this is supported. I just think we should allow the *Deco* documentation to say you can legitimately test this with Plone 4.2 or whatever. That means we may need to PLIP things for 4.x that enable Deco to work well, or backport things that otherwise would be in Plone 5 only, if they can benefit users of 4.x. The reasons to do this would be to reduce the risk of Deco bitrotting because no-one is able to use it except in super-experimental setups. It won't be a mainstream option until Plone 5, but some greenfields projects may be able to become early adopters if we don't make it *too* difficult for them. - I think we want WSGI as a supported deployment option in 4.x, 5.0 at the latest, via the Zope 2.13 WSGI work WSGI capability will be in Zope 2.13 / Plone 4.1 and while it will certainly be considered experimental rather than supported at first, I expect people will start gaining experience with it. I'm hopeful that we might be able to *require* wsgi for 5.0, but that will depend on how things work out over the next year or so with 4.x. Right. I think this is similar: a legitimate option for those who know what they're doing and are willing to help build the future. Martin ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team signature.asc Description: This is a digitally signed message part ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Plone roadmap
With the release of Plone 4.0, I thought it would be useful to set out my understanding of where we are headed with future releases. This draws heavily on conversations with Hanno and focuses on infrastructure rather than user visible changes. The intention is to spark a discussion from which I'll write up a roadmap on plone.org or dev.plone.org. All plans are of course subject to change - but it is useful to set out a direction. Over the years, Plone has accrued much code and added many concepts. In part this is a reflection of the vibrancy of the project, but it has come at a high cost in complexity. Hanno has been doing heroic work with Zope 2 and the ZTK recently, and we will soon be able to completely avoid the large chunks of old Zope 2 code we do not use at all. Acquisition --- Acquisition was introduced because the ZODB did not support reference cycles. As a programming paradigm though – at least in the implicit form used within Zope 2 – it has been a failure. It is strange and unfamiliar to new developers. It also prevents us from using some natural patterns: the catalogue indexes content by path rather than directly; references between content must be indirected through a path. Phillip and Hanno's work to enable Acquisition over __parent__ pointers (included in Zope 2.12 / Plone 4) has given us a path out of our current dependency on it. This has already simplified BrowserViews. The next step is to make sure all content has __parent__ pointers all the way to the application root. We should do this for Plone 5 and drop Acquisition entirely in a future version. http://wiki.zope.org/zope2/SetParentAndNameInOFS Catalogue and References Once all content has __parent__ pointers to the root, we will be able to use standard ZTK catalog components. Using zope.intid for the catalogue keys allows result sets to be merged across catalogues. We'll also be able to store relations as simple references on content - related items can be stored as a simple list of objects on a piece of content. These can then be indexed in zc.relation directly. Archetypes -- Plone 5 should be the last major release with Archetypes compatibility. For form based content types, Dexterity is the future. The Publisher - The Zope2 publisher has become incredibly complex, with numerous different hooks. In the long run (Plone 6?) we should replace it with our own simplified publisher which runs only in a WSGI pipeline. There will be a lot to learn from BFG here, though that is probably too simplistic for Plone. OFS and CMF --- Currently, all Zope2 content inherits OFS.SimpleItem. All Plone content also inherits from CMF. In the long run, content items should have simple classes with code in views. These are significant changes and are likely to be the most difficult. Restricted Python - This is another confusing hurdle for new developers and should be abandoned. Form Controller --- Other than the Archetypes edit forms, it would be best to remove all other uses. Tools - The various tools should become utilities and views. Most of them need not be persistent as settings can be stored with plone.registry. Skins - Old style templates should be replaced with views. CSS/JS/Images should all migrate to resource directories. Python 3 In three to five years time we will have to have moved to Python 3. It seems likely that there will be others to help the ZTK porting effort, but little interest in porting Zope2. For the time being then, our focus should be on progressively removing our Zope2 baggage. WSGI Various components should be move out of Plone and into the WSGI pipeline. This should allow us to share code with other projects. Prime contenders would be: * Authentication * Resource registries Laurence ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
