[Grok-dev] Re: Admin UI name change suggestion

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Philipp von Weitershausen wrote:
> Martijn Faassen wrote:
>> Philipp von Weitershausen wrote:
>> [snip]
>>> grok.Application is a bit of a confusing itself, I think. Especially 
>>> when we allow WSGI, we'll have a "WSGI app" which is distinctly 
>>> something different from the "grok.Application". The "WSGI app" is 
>>> more like what you consider an application above: something that you run.
>> That's an interesting point. We have two levels here that are crossing 
>> over and confusing people:
>>
>> * starting applications in your OS. Of course in some cases someone 
>> *else* might be running the server in which case you won't have to do this.
>>
>> * web applications. In many cases someone else is running the web 
>> application for you so you don't see these either, except as URL.
>>
>> Basically we have "applications in an application". We could call the 
>> outer application "application server" to avoid this confusion. An 
>> application server can run one or more grok.Applications.
>>
>> I'm not sure how WSGI app fits in this. Could you elaborate?
> 
> A WSGI app is the thing that deals with incoming requests. In any Zope 
> application, this task will be handed off to the publisher, of course.

In the WSGI termset, the "application" is the thing onto which the
server dispatches requests:  it can be either:

 - A single callable, taking the WSGI environment and returning the
   response (some details elided).

 - A "composite" of similar components, each of which wraps the next
   one in line.  In this sense, all the layers except the innermost
   are called "middleware" (because they play both the role of the
   "WSGI server", w.r.t. the "next" layer, and the "WSGI application",
   w.r.t the "prior" layer.  In this setup, the innermost layer is
   sometimes misleadingly called the "applicaiton", or the endpoint.

In the Zope world, the publisher (or some analog) probably sits at that
innermost point.  Some of what the current publisher does can be
factored out inot middleware, but the core operations (traverse an
object graph to find the publihsed object, call it, map the response
onto what WSGI expects) cannot.


> The publisher turns the WSGI streams and environments into nice objects 
> (request and response), and then traverses the object hierarchy, finding 
> our grok.Application. This is really just one object in the object graph 
> that is traversed over. I think it deserves a better name. It's only 
> conceptually an application to us.
> 
> Note that web applications that build on Zope, meaning their WSGI app is 
> really just a shim over the Zope publisher, can still have a lot of 
> control over how the application is started up in the app_factory (a 
> PasteDeploy thing). Typically, applications want to parse zope.conf 
> here, then execute site.zcml and then open ZODB databases.
> 
> I think it is very useful to be able to override things here on an web 
> application per web application basis. That's why the app_factory is 
> always defined in each project generated by zopeproject (and the same 
> will happen for grokproject soonish). For instance, you can easily 
> create ZODB-less appliations this way (provided that you find a 
> publication implementation that doesn't need one) because the startup 
> code is in your control.

For a concrete example of how this stuff can be broken out, I'd like to
invite folks to look at repoze:

  http://repoze.org/

which has the following goals:

 - Make the server / publisher part of Zope more reusable, configurable
 , and maintainable.

 - Allow for better interoperability with the other Python web,
   frameworks, both by reusing their components and by making Zope's
   unique features more easy for them to use.

One interesting example of the framework is the 'repoze.kiss' package,
which serves up dynamic content from the filesystem by tricking the
Zope2 publisher mashinery into publishing a non-ZODB based root.  There
is a version of the repoze site running using kiss and deliverance (for
themeing) at:

  http://kiss.repoze.org/

That version will likely replace the main site, after a little further
shaking down.



Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHHMEd+gerLs4ltQ4RArP8AKCwC4kyFHDVdfh6qIKxmDscZ1NzmACfXHeD
XLNn5v4M3JXwWjVdbC//tu8=
=UnFL
-----END PGP SIGNATURE-----