Re: [Framework-Team] Plone roadmap
On Fri, Oct 22, 2010 at 12:07 AM, Martin Aspeli wrote: > On 21 October 2010 22:55, Chris Calloway 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 21 October 2010 22:55, Chris Calloway 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 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 Wed, Oct 6, 2010 at 8:34 AM, Chris Calloway 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
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
>> 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
-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- <>___ 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 wrote: > On Sun, Sep 5, 2010 at 7:17 PM, Martin Aspeli > > > wrote: > > On 5 September 2010 15:29, Hanno Schlichting > 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 Wichert Akkerman 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. I disagree with that characterization: it turns out that most "silo" apps want to take control of exactly *one* part of the authentication dance (the login view), but many *don't* want or need to control the rest (authenticating post-login cookie-based credentials, for instance). Although many coders might feel more comfortable with driving everything "bare metal", such apps are likelier to screw up authentication than if using a "cooked" configuration which Just Works (TM). "Bare metal" also loses bigtime when you need to integrate more than one application into a single authentication domain (SSO, shared login views, etc._ repoze.who 2.0 provides an easier-to-use API for apps which want some or all control, while still leaving it possible (and well supported) to use middleware for the parts the application does not need to control directly. See the who docs on the various models: http://docs.repoze.org/who/2.0/narr.html#using-repoze-who-as-wsgi-middleware http://docs.repoze.org/who/2.0/narr.html#using-repoze-who-without-wsgi-middleware http://docs.repoze.org/who/2.0/narr.html#mixing-middleware-and-api-uses Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkyGP6gACgkQ+gerLs4ltQ7ZZgCfYv9Q3ygq8FgVhxMMR4mz+CEe GmYAoNA1y421LlPV3No372eFSIQY04+F =6ddH -END PGP SIGNATURE- ___ 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 wrote: > If I'm allowed to get one suggestion in there: > > On Thu, Sep 2, 2010 at 3:39 PM, Laurence Rowe wrote: > >> 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) > 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 > 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
If I'm allowed to get one suggestion in there: On Thu, Sep 2, 2010 at 3:39 PM, Laurence Rowe wrote: > 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) 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 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
On Sun, 2010-09-05 at 15:35 -0400, Chris McDonough wrote:
> >
> > 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).
I should also note that we had our own "login application" which didn't
require any help at all from an external form (the normal "FormPlugin"
in r.who, which both renders a login form and posts to itself).
Literally zero people wanted this (I mean, literally no one). They all
had integration requirements that they felt more comfortable servicing
within the framework that they were creating their app in.
- C
___
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 wrote:
> > On Sun, 2010-09-05 at 18:18 +0200, Hanno Schlichting wrote:
> >> On Sun, Sep 5, 2010 at 5:46 PM, Wichert Akkerman 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
>
> 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 5 September 2010 20:01, Laurence Rowe wrote: > On 5 September 2010 19:17, Martin Aspeli wrote: >> On 5 September 2010 15:29, Hanno Schlichting 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
On Sun, Sep 5, 2010 at 7:17 PM, Martin Aspeli wrote: > On 5 September 2010 15:29, Hanno Schlichting 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. The various search methods in the catalog all have actual keyword arguments which govern part of their behavior. I want a clear distinction between "the query" and the different keyword arguments on the search methods. We also do a couple of operations on the query dict, rewrite it to some degree and pass it on between methods. Currently there's a good deal of code to first merge all the different ways of passing the query and bringing it into a canonical dict form (see Zope 2.13 Products.ZCatalog.Catalog at the beginning of searchResults, the CatalogSearchArgumentsMap class and the make_query method). All that code can go away once we just get a dict in the first place. This will also make collective.solr simpler, as it has to do the exact same on its own so far. It needs to rewrite the catalog query syntax into the Solr syntax. To my knowledge none of the various forms of constructing the query is more common or more advertised. The oldest one was using a request object, which some people figured out could just as well be a simple dict instead. The simple dict approach is what I've seen the most. Passing keyword arguments was another way, but is not more common or advertised to my knowledge. >> - 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? In order for merging of result sets across catalogs to be efficient, it needs to be integers and not strings. It's likely that querying one catalog only does a minimal restriction and gets you 100.000+ results and only merging it with the restriction from a second catalog will bring it down to a smaller number. At this scale the difference between IISets and sets of strings is significant. >> - Once we have parent pointers we can probably ditch storing metadata >> in the catalog and load objects directly. > > Why do __parent__ pointers help here? Once we have parent pointers, we don't need to traverse to the object anymore to construct its Acquisition chain. We can just do the moral equivalent of "connection.load(poid)" and use the result. As long as we have all the traversal overhead (like with five.intid), there's still a large overhead cost for this traversal. >> 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. >> - For Plone 4.2 I want to get rid of CMFDefault (there's too much UI >> code in it, which is useless to Plone) > > Is there anything that people regularly import from CMFDefault? I can't > think of anything other than perhaps Document being used in some tests. I'm not aware of anything. There's some bits of DublinCore base classes in it, some base parts of the Portal object and some site creation logic we use. Once we have plone.app.discussion we don't need DiscussionItem anymore. Other than that there's bits of tools code for the registration tool, membership tool and metadata tool. We probably overwrite 80% of the code somewhere in our own versions anyways for these. I did this removal once already for my Plone trunk work and it's not been too difficult. >> Remaining are CMFCore, DCWorkflow and GenericSetup. I don't think we >> can get rid of any of them in the foreseeable future. > > Do we have to? I quite like those bits. :-) > Well, CMFCore is maybe a bit bigger than we want it to be, but still. I want to completely get rid of Acquisition before we move to Python 3. You cannot
Re: [Framework-Team] Plone roadmap
On 5 September 2010 19:17, Martin Aspeli wrote: > On 5 September 2010 15:29, Hanno Schlichting 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. Laurence ___ 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 18:47, Chris McDonough wrote:
> On Sun, 2010-09-05 at 18:18 +0200, Hanno Schlichting wrote:
>> On Sun, Sep 5, 2010 at 5:46 PM, Wichert Akkerman 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.
Laurence
___
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 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 call
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 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 Sun, Sep 5, 2010 at 5:46 PM, Wichert Akkerman 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 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 AkkermanIt 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
Hi.
Some more lengthy points :)
On Thu, Sep 2, 2010 at 9:39 PM, Laurence Rowe wrote:
> Catalogue and References
>
>
> Once all content has __parent__ pointers to the root, we will be able
> to use standard ZTK catalog components.
Except that the standard ZTK catalog components are much too
simplistic for our needs. The ZCatalog, PluginIndexes and various
catalog add-ons we have would need to be reimplemented. I think we can
use zope.intid and zope.keyreference (once we have parent pointers),
but will need to write everything else from scratch.
As this is a big task, I think we need to do some smaller steps:
- 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. 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
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.
- With Zope 2.13 and going forward I'll extend and improve the
ZCatalog some more. queryplan, slow query logging with ZMI reporting
are already in. Next up are things like specialized indexes for
boolean values (so the ATCT boolean criteria doesn't have to query for
"[0, '', False, '0', 'False', None, (), [], {}, Missing.MV]" anymore),
a "unique value" index to efficiently hold data for the UID index,
incorporating fixes from enfold.fixes to avoid the conflict error
hotspots in the catalog and finally merging in a cleaned up version of
the unimr.compositeindex (a multi-column index). I also want to put
batch handling into the catalog in the same way collective.solr does
this. Instead of querying for all content and then wrapping things in
a batch class to access just a particular batch of 20 items, we should
pass the batch information directly into the catalog and allow it to
just give us the 20 objects we are interested in. I think there's some
more we can do here and currently it's much easier to improve these
things inside Zope2.
- Clean up the default indexes and metadata used in Plone, for example
move the Title and Description index away from being ZCTextIndexes.
- 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.
- Define the actual contracts to re/index only part of an object and
implement this in the new event approach. For example imagine you
change the value of the "title" via setTitle, the field is called
title, the accessor is Title and there's both an index named Title and
one called SearchableText that indexes this value - what name do you
actually pass into the equivalent "reindexObject" event and who's
responsibility is it to notify all indexes that are interested in this
value? How do you deal with custom methods tracking the title field or
plone.indexer wrappers? Currently we always have to reindex the entire
object, as these dependencies are all unclear or there's no way to
specify them (well you can pass in index names right now, but the
index name doesn't have to be the same as the actual indexed attribute
and you have no idea if there's other indexes that also index "your
data" making the whole thing rather pointless).
- Once we have intid's we can change the internal unique id of the
catalog from the physical path over to an intid. This will allow us to
rename or move "top level" folders without loosing all index
information and indexing the entire subtree from scratch. In
combination with the above "partial reindex" contracts, we should be
able to index only the indexes which are dependent on the physical
path. It will also allow us to do queries across multiple catalogs
with reasonable speed.
- Once we have parent pointers we can probably ditch storing metadata
in the catalog and load objects directly. This depends on having
content with a sane persistent structure. Having blobs for large data
already helps a lot, but Archetypes BaseUnit indirection is certainly
not sane enough for this to work.
Next to these things we'll probably do more work with Solr for
indexing textual data, which will get us further on things like
facetting, spell correction, auto-suggest and binary data extraction.
Maybe someone might also finish "NOT" support in ZCatalog (there's
some half-finished patch for it in the Zope2
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 wrote: > > On 2 September 2010 22:16, Martin Aspeli 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
Re: [Framework-Team] Plone roadmap
On 3 September 2010 17:03, Laurence Rowe wrote: > A few more points: > > Security > > > The current AccessControl security model has served us well. While > some simplification may be possible by dropping unused legacy > features, no major changes to functionality should be expected. > Porting to Python 3 will be the obvious time to make any > simplifications. I agree that the model is good. However, I've spent more time with a pdb deep into AccessControl than I'd care to think about. The code is quite obscure and difficult to debug, even with "verbose security". I think we need to clean the code up and document it properly. How many people know how the various permission attributes work, for example? Martin ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone roadmap
A few more points: Security The current AccessControl security model has served us well. While some simplification may be possible by dropping unused legacy features, no major changes to functionality should be expected. Porting to Python 3 will be the obvious time to make any simplifications. The ZODB While it is unfamiliar to new developers, building on top of ZODB is hugely beneficial to Plone. Semi-structured content management data just doesn't map well to relational databases. That said, by reducing our expectations on content types, it should become easier for add ons to integrate relational database backed content into Plone. Portlets and Viewlets - Portlets and viewlets are powerful concepts but they have proved a difficult stumbling block for new developers. The Deco project is working increased layout flexibility for content editors. It also makes it much easier to create dynamic page fragments in the form of 'tiles'. These will replace portlets and most current uses of viewlets. Laurence ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone roadmap
Hi, On 3 September 2010 15:18, Laurence Rowe wrote: > On 2 September 2010 22:16, Martin Aspeli 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
Re: [Framework-Team] Plone roadmap
On 2 September 2010 22:16, Martin Aspeli 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 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. Laurence ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone roadmap
I'd like to see some action and discussion on this in Bristol, who's in? On Thu, Sep 2, 2010 at 11:16 PM, Martin Aspeli > 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. > > - 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 > > Martin > > On 3 September 2010 04:39, Laurence Rowe wrote: > > 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/framewo
Re: [Framework-Team] Plone roadmap
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. - 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 Martin On 3 September 2010 04:39, Laurence Rowe wrote: > 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 > ___ 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
