[Grok-dev] Re: 0.14 todo list

[Philipp von Weitershausen]

Martijn Faassen wrote:
> A while ago I wrote a wishlist for improvements in Grok 0.14. We've had 
> some discussion then, and some more development, so let's turn this into 
> a TODO list:
> 
> * grokcore.view - useful in five.grok, but also useful as a stand-alone 
> component in a Zope 3 context. (Godefroid Chapelle, Lennart Regebro, 
> Philip von Weitershausen). We need to push this towards a release and 
> merge this with the Grok trunk. Looks like Philipp made some headway 
> towards separating out something like grokcore.form as well.

Yup. grokcore.view is ready to be split up into grokcore.view and 
grokcore.formlib (I feel better about this name since the underlying 
framework that it wraps is called zope.formlib). I already split 
grokcore.security away from grokcore.view.

> * grok.skin directive on interfaces that subclass IBrowserRequest 
> (Jan-Wijbrand Kolman). This should result in a simplification of the way 
> skins work in Grok, reflecting better the way they actually work in Zope 3.

Indeed. I'd like to wait for JW's work to land in the trunk, then factor 
it into grokcore.view (because that's where this stuff actually lives 
now). After that I'd like to get the grokcore.xxx branch merged as 
quickly as possible. It will introduce three new dependencies:

* grokcore.security
* grokcore.view
* grokcore.formlib

> * WSGI in Grok (Philipp as driver)
> 
> * Paster to start Grok (Philipp as driver)
> 
> * Development/deployment profiles with useful WSGI middleware (Philipp 
> as driver)

These are all related, of course, but that doesn't mean they all need me 
as a driver. I'd be happy if more people were to explore the last bit, 
for instance...

Earlier this month I briefly visited with Zope Corporation and had a 
little chat with Jim about WSGI integration. We basically agreed on the 
new way to go with zope.publisher.paste, publication factories, etc. THe 
good news is that it'll all be much simpler with what we have in mind. 
The bad news is that it will take some sprint-level coding for which I 
will have to make time. Perhaps I shoudl write down the ideas so that 
other people could have a go?

> * relative REST, i.e. optionally exposing something like <content>/rest/ 
>  for REST access (Craeg Strong as driver. Craeg, do please start a 
> design discussion. Could possibly also be done as a Grok extension)
> 
> Anything else to put on the list?

Model-based security.

> I think we should get 0.14 out of the 
> door sometime in september, and the WSGI stuff is already quite 
> ambitious, but if we have people willing to do the work we can certainly 
> consider more.

I'd also like us to think about the 1.0 roadmap at some point. I think 
we could use a 1.0 release after nearly 2 years of development :).

My suggestion is that we should have a 0.xx release that basically 
resembles what we think 1.0 should look like. Then, after the dust has 
settled (few weeks or months after), we should release 1.0 which would 
look much like 0.xx. THis 0.xx would be a beta release, so to speak. As 
far as I'm concerned, 0.14 could be this last 0.xx release before 1.0, 
but other people might have other opinions, which is fine. I'd just like 
us to think about 1.0 if that's ok.