[Repoze-dev] Re: Invitation to a dance

[Tres Seaver]

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

Martin Aspeli wrote:

> If you guys are doing what I think you're doing ... ;-) This is
> pretty amazing. How long did you spend on it?

On and off over a couple of weeks.  Much more fun than the customer work
which was the alternative. ;)

> A few questions come to mind ...
> 
> I haven't been able to look at any of the code, but am I right in 
> assuming that there's no traditional Zope instance involved here at 
> all - the Zope code is in 'zopelib', and you're not necessarily using
>  all of zopelib: the bits that do publishing, transaction management 
> etc are refactored/rewritten into repoze.* packages?

Mostly right.  The "isntance" is actually a virtual python environment
(created by the 'sandbox' command).  We like the "virtual python" model,
in general, and would like to move to using the 'virtualenv' stuff.

In fact, one of our ambitions is to write an application which
front-ends VE's replication stuff to create a custom bootstrap.  At this
point, that is mostly vapor.

> Have you tested whether this works with other WSGI things, such as
> the Pylons-like in-browser pdb exception filter, or having
> Deliverance in the pipeline?

Yes, that was a major driver.  We've used both of those as middleware
(Paul is happily skinning Plone via Deliverance as I write).

> How did you get Plone to run? Did you have to eggify all its 
> Products.* packages, or is there a model that still works with a 
> product-path as well? Did you need to change Plone to make this work 
> in any other way?

There is a 'ploneproducts' egg which holds all the eggs in the
'Products' namespace, except for those which are available as separate
eggs ('Products.{PluginRegistry,PluggableAuthService,GenericSetup}'),.
The 'plonelibs' egg contains all the non-product packages (why aren't
those eggs already in Plone3, BTW?)

There is a helper script, 'installproduct', which will create an egg
from a sufficiently well-behaved product checkout.

> What do you anticipate will be problematic, i.e. what will you just 
> need to deprecate and tell people not to use? Implied in that 
> question, of course is, what's the migration path for people who want
>  to move to this?

application code won't change much, if at all:  if it does, we've missed
our goal, which was to break apart the "application server" part
(ZServer + ZPublisher) frmo the "application".

The README for repoze.zope2 actually talks about this::

>> The Default Sandbox Configuration
>> 
>>   The configuration of WSGI components in the sandbox setup form a
>>   publishing environment in which most Zope applications should be
>>   able to run without modification.  Some of the jobs previously
>>   filled by components in Zope have been assumed by repoze and other
>>   WSGI middleware components:
>> 
>>   - The job of ZServer has been filled by the zope 3 WSGI server (via
>>     repoze.zope2.server).
>> 
>>   - The job of ZPublisher object publishing has been filled by the
>>     object publisher in repoze.zope2
>> 
>>   - The job of ZPublisher transaction management has been filled by
>>     repoze.tm middleware.
>> 
>>   - The Zope 2 "error_log" has been replaced with error-catching /
>>     error-logging middleware in Paste.
>> 
>>   - "access" logging can now be handled by a middleware component.
>> 
>>   - The job of VirtualHostMonster is now filled by repoze.vhm.

One change which we discussed, but punted on, was to ignore
'__before_publishing_traverse__', and make the application supply such
behavior via traversal adapters instead.  There aren't that many places
which use the hook:

 - VirtualHostMonster does, but we'd like to make that one middleware,
   and just mutate the "standard" CGI environment to get genereated URLs
   correct.  Right now, repoze.vhm mostly does that.

 - CMFCore's skin machinery needs __b_p_t___, but could easily be moved
   into a traversal adapter (we have a rough proof-of-concept already).

 - The DynamicType stuff depends on it, but that is even more bogus;
   it should definitedly be done via traversal adapters.

However, at the moment, the 'repoze.zope2' publisher helper ("obob"
plugin :) is still calling '__before_publish_traverse__' hooks,


All that said, there do seem to be some bugs in the current repoze.plone
distribution which are probably related to publishing changes.  Plone3
is running behind mod_wsgi at the following URL:

 http://www.repoze.org/tmp/plone


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

iD8DBQFG/T5G+gerLs4ltQ4RAuB6AKCtcYE8Z+x+SpeBBjIK/6Mgw3AIMACgicaZ
jfkzxVCGQRvhFzRffaEttIM=
=Jcs2
-----END PGP SIGNATURE-----
_______________________________________________
Repoze-dev mailing list
Repoze-dev at lists.repoze.org
http://lists.repoze.org/mailman/listinfo/repoze-dev