[Cubicweb] meeting with Paul Everitt "a Pyramid guy" on July 31st 2014 at Logilab

Christophe de Vienne christophe at unlish.com
Mon Jul 28 19:48:20 CEST 2014

Le 28/07/2014 19:03, Adrien Di Mascio a écrit :
> Hi everyone,
> Le 28/07/2014 16:50, Christophe de Vienne a écrit :
>>>> Note that it does'nt mean we remove the cubicweb registry for view
>>>> selection in general (yet), just that we can bypass it for the
>>>> top-level view.
> I'd like to hear what there is behind "(yet)" in the statement above. 
> Maybe thursday ?

Basically, at one point we will want to see if the pyramid registry can 
be used (or not) as a base or a replacement for the cubicweb one.

It is not a subject we want to rush into, and it might be postponed for 
a while.

>> I have a feeling that this particular subject is almost a bonus for
>> thursday. I would like to work on it asap (I did since the beginning of
>> this experiment), but I know other things needs to be done first.
> I haven't followed closely the "cubicweb on pyramid" but this specific 
> point looks peripheral to me.

I would not call it peripheral as it will be an important piece for 
removing code from cubicweb. But it will come in a second step after the 
initial plug between the two frameworks.

>> That said, I would like to know logilab developers expectations about
>> this day (mine is to validate the path we are taking and agree on a
>> roadmap).
> The idea is to remove from cubicweb what is done better elsewhere and 
> to benefit from external modules, plugins, middlewares, whatever.
> You thought Pyramid was a good choice and I also believe it is. My 
> initial questions were :
> - would that offer a better authentication API, would be benefit
>   from pyramid external authentication plugins for free ?

Yes, and that is a spectacular success of the already existing 
pyramid_cubicweb library.
With it, CW transparently uses the authentication system of pyramid, 
meaning any authentication policy of the pyramid ecosystem can be used.

> - would that offer "persitent sessions" for free ?
Yes, and it already does. With the current implementation, cubicweb 
session data are managed by the pyramid session handling API. The 
default policy I used is probably not the right one, we just have to 
choose what we want by default.
And the beauty of it is that we can already use any session data backend 
provided by pyramid : files, cookies, redis, memcache... We can also, 
and I think we will, provide a CW-database based handler for easy startup.

> - would that offer better caching ?
I have no easy answer to that, but I am pretty confident that the tools 
accessible via pyramid will make improving the cache issues easier.

> - would that provide nicer routes ?
A little different (not much), very well documented, and imo nicer.

> - how does it handle content-negotiation ?
> - could we easily  implement the "debugconsole" prototype / hack we
>   wrote two years ago using the pyramid debug toolbar ?
We can already access a debug console for each frame of the stacktrace. 
It that is what you mean.

> - how would "cubes" be handled ?
Same as today to begin with, but if (when) we switch to venusian for 
scanning resources, we may feel the need to change a few things.
In any case, talking about this subject needs more experience with both 
frameworks working together. So we should not start a discussion about 
it as it would lead nowhere.

> - how does pyramid handle resources (javascripts / css / images) ? Does
>   it provide helpers and workflows to use tools such as webasset or any
>   node-based solutions to optimize resources ?
webassets integrates nicely with pyramid. It is an external dependency, 
and pyramid only provides what is needed to serve static resources 

> - should we provide a cubicweb scaffold or should we just "wrap" an
>   existing cubicweb repository instance ?
The current approach is to wrap an existing repository instance, which 
means we remain very compatible for existing cubes, and by-pass a few 
things from the cubicweb stack, like authentication.

With time, more parts will be bypassed (or removed) from the current 
cubicweb stack and be reimplemented in a pyramid way.

> I know that some of those points have been discussed on the 
> mailing-list but I couldn't take the necessary time to dive into this.
> Thus what I expect is basically answers to (some of) those questions. 
> I'm not sure one day is enough to talk seriously about everything but 
> we could at least start the day with :
> - a short introduction to what Pyramid is (isn't) by Paul,
> - a summary of your (Christophe) current work on the subject,
> - try to agree on a sensible path to continue the ongoing effort,
> - and hopefully hack a bit and make sure we can start some of
>   our instances with pyramid_cubicweb ?

Sound fine to me!



More information about the Cubicweb mailing list