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, for example.

Dexterity has already figured out how to bridge this with the CMF
portal_types tool. If and when the CMF stuff (like the FTI object
construction logic) starts to disappear, what remains is pretty clean and
simple.


> > 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
>
> * error / exception handling
> * virtual hosting
>

Please yes. The repoze.vhm approach with request variables is so much more
sane.


> * profiling / debugging (repoze.profile and WebError are much nicer
> than PythonProfiler or PDBDebugMode)
>

And ditto.


> - 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.


> - CMFEditions should probably use plone.uuid or a custom id generation
> logic instead of CMFUid, which allows us to get rid of CMFUid
>

My vote goes to plone.uuid, of course. ;-)


> 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.


> 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. Once we have this, we can clean up and reduce the
> dependencies of all user related API's. There's still a huge bunch of
> weird and complex code, as we have CMF specific API's that know
> nothing about PAS, PAS specific API's that are generally unfriendly to
> use and GRUF legacy code. Member and group data handling is one such
> neglected area - something that we might improve when improving
> Plone's "social" capabilities.
>

I think cleaning up the non-PAS bits should be a priority. PAS is actually
quite nice. There are a few API weirdnesses (user property sheets come to
mind), but getting rid of some of the portal_memership/memberdata stuff in
favour of PAS APIs is probably a good idea.

Martin
_______________________________________________
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Reply via email to