The PyKE (Python Knowledge Engine) may offer a useful way to capture and store (compile as “plans”) any number of “dynamic” pipelines, based on declarative rules about introspectable (is that a word!?) features. Ultimately, that’s what PyKE is for, to enable compiling an arbitrarily large range of possible solutions into re-usable plans, matched to present conditions via a rule-base.

The excerpt below is submitted strictly as an _example_ of the kinds of code re-use that PyKE makes possible. Dynamic is wonderful, but once you’ve crunched through a solution, store it! Then, call it back on demand, when similar rules apply. Think WSGI widgets as “functions”, piped together as defined in the appropriate plan. If such a plan doesn’t already exist, it may be “discovered”, and _next_time_, it will already exist …

“it occurred to me that backward-chaining could be used to automatically figure out how to join database tables together and generate SQL statements.

And if the backward-chaining rules could see which substitution variables are needed by an HTML templating system, it could automatically generate the SQL to get these data and build the code to update the template.

It seemed that it would no longer be necessary to include anything that looks like code in the HTML templates. The graphic designers could just add simple attributes to their tags and the backward-chaining system would figure out the rest. This would mean that the programmers don’t need to modify the HTML templates, and the graphic designers could maintain full ownership of the HTML.

I had a WSGI front-end that would simply assert the data passed to it as facts.

The forward-chaining rules took these starting facts, parsed the cookie information, form information, browser information, and url, determined whether the user was logged in, figured out which client the request was for, established all of this as additional facts and activated the appropriate rule base for this client.

Then the WSGI front-end simply asked for a proof of the process() goal and executed the resulting plan function which returned the final HTTP status codes and HTML document.”

http://pyke.sourceforge.net/Py.....al-results

Thanks for all the Zope,
Jerry S.

Great to see you working on Zope again!

I think I’d like to understand slightly better how this relates to the Repoze stuff. Conceptually, at least, there seems to be some overlap, though I understand the backwards compatibility question may make some things different. Still, middleware like repoze.who and repoze.tm2 sound like good candidates for re-use rather than re-invention. These are already used in the wild outside Zope-ish applications.

Martin

P.S.
We should get your blog onto planet.plone.org. If you want that, you can put in a ticket on http://dev.plone.org/plone.org with an RSS URL.

Martijn: right, no tests yet, and I suspect there are even syntax errors. Tests are next.

Once your design has stabilized the grok project will investigate creating a grokker to register pipeline stages.

zope.pipeline is starting to look good! It looks like a really elegant way to compose a pipeline of endware.

Shane: it’s great to see you working in Zope again!

Chris: the zope.pipeline.entry module caches the pipeline by request type (it uses tuple(providedBy(request)) as the key), so it should be plenty fast. Static pipelines should be easy because everything in zope.pipeline.apps is intended to be usable directly by tools like Paste Deploy. We might break out some of those applications into their own packages or even just replace them with Repoze apps.

The “more configuration than a name” requirement is still bothering me a little, though. I haven’t yet figured out what I should do about that. I invented a solution but I’m not happy with it.