Content from what Ian is up to , August 16 2006 and before:

August 16:

• I'm going to move all the notes today/yesterday to Ian's thoughts on Deliverance .
• Who loves paperwork? Me!
  

August 15:

• Back to Deliverance again. I've decided I need to understand it a little better. Which mostly means understanding XSLT, since most of it is implemented in the form of XSLT. Started with XPath then XSLT; not too hard, I suppose. This XPath tester was helpful. Now to figure out how Deliverance itself actually works. Thoughts moved to a different page.
  
• Lots of testing conversation on IRC...

August 14:

• Back to Deliverance stuff. Got the tests running, everything in vaguely good shape. However, documents are loaded up statically from the filesystem, not using URIs, which isn't as slick. I'll need to do some work with a custom document loader that uses WSGI to fetch documents and subdocuments. Probably AppMap will go away in the process, as it's just a thin wrapper around the XSLT stuff, most of which won't apply anymore.
• The Zope/XML-XSLT/etc stuff tires me out after a while; to regenerate myself, I think I'm going to work on a fast path for RPC/HTTP calls in a WSGI process, so JSON/XMLRPC/etc calls can be made with very little overhead (but will turn into normal HTTP calls if necessary). I've had some ideas in my head for this for a while. This would apply to tagger and some other service-based systems. Generally speaking anything that runs in a WSGI container should be able to contact anything in the same container with very little overhead (e.g., Plone under topp.zwsgi to some other system).
• RPC stuff has gone here.
  

Over the weekend:

• Wanted to mess around with URL polling. Got annoyed that there wasn't anything that I liked for doing periodic tasks, especially lightweight tasks (not in a subprocess like cron).
• Started PyPeriodic.
• Didn't get very far; mostly a date-interval-parsing routine, and some brainstorming about a config file. Decided I didn't like my config file options. Expanded INITools to have a ConfigParser mode, but with some added features (mostly trackability). I want to add concepts of extending to it, similar to what both zc.buildout and Paste Deploy do with config files. The ConfigParser backward-compatible portion is pretty much done (yeah for pre-existing regression tests!). Note that unlike other config parsers, this config parser does not (and will not) add major features over the stdlib ConfigParser. I used ConfigObj just a little at one point, and found the added features quite distracting; once things get that complicated, it's better to move stuff out of configuration and into code (IMHO).
  

August 11:

• Started the zc.buildout project for our internal Zope/Plone/etc buildout, in topp.buildout -- the checkout (from what I can tell) is also supposed to be the thing that gets built out.
  

August 10:

• Returning from Vancouver
• Got the presentation finished: slides and documents (both are quite large), also some code examples which effectively recreate much of Paste in a more approachable (but really quite equivalent) form
• I'm having a hard time focusing on Deliverance right now -- I'm going to look at zc.buildout instead
• After looking at zc.buildout, it makes more sense to me. I'm going to try to do our deployment as a buildout with recipes. zc.buildout is really a config file setup and some other basic glue around "recipes" which are themselves just installation/deinstallation scripts. A set of these recipes makes a complete system. This is actually a lot like Paste Deploy.
  

August 1:

• Stupid Linux. Getting the laptop working fully is a pain in the neck.
• Doesn't help that I had other half-broken hardware.
• Lots of time spent on the presentation, more than I expected.
  

July 31:

• I should check out the IT Resource Center sometime (a non-profit IT support place in Chicago)
• Working on packaging Deliverance as a normal Python package (in this branch)
• Messin' around with my laptop
  

July 28:

• Phone conversation
• Should start looking at Deliverance, and this branch
• Need to get commit to that repository; lost password. Should contact philiKON on IRC
  

July 27:

• Need to look more closely at this.
• Trying to get topp.zwsgi properly tested, and get the WSGI app embedding part working
• Maybe should use these tests
• Maybe I'll figure out what this means
• Putting stuff in here to restart Firefox so I can get this extension installed -- something new people should have installed too (well, it didn't really want to install -- cookie crumbler was also stubborn)
  
• Got PloneTestCase working with topp.zwsgi -- it doesn't test much yet, but it's a proper fixture (of sorts). You can do SERVE=t python topp/zwsgi/tests/testZopeAsApp.py to start up the test environment over HTTP, which is interesting, though maybe not super helpful. Still haven't figured out how to log in in that case (test_user_1_/secret should work, but doesn't).
  

July 26:

• Phone calls and stuff
• WPHP works now
  

July 25:

• First substantive commit to topp.zwsgi:
• I'll need some help with the tests, as the test currently just uses the Zope instance I set up (and so is tied to my environment). ZopeTestCase's setup should be used, while using WSGI-based functional tests.
• Also, it needs more thorough tests, but without known content on the Zope end I can't do functional tests.
• Ideally there would be an app with functional tests that I might be able to use, basically confirming that the app looks the same when piped through WSGI and when using zserver directly. Using wsgi_intercept, HTTP-based functional tests could be applied to Zope, including a zope.testbrowser-based test. Looks like CMFPlone has some functional tests written with zope.testbrowser (Five.testbrowser specifically, but the tests should work with either). This would be a good candidate, using PloneTestCase to build up the fixture.
  
• Started work on the other end -- embedding WSGI apps in Zope -- but I'm not sure how to actually put such an object into Zope. This involves Zope Products and all that jazz, which I don't know anything about. I need to find an ideal/simple project to take hints from. This tutorial might be good to start with.
• Some discussion with Daniel Nouri about ZopeSkel. We agree it should build a working example and a test for said example.
  

July 24:

• Deployment: I'll be deploying the software on my local machine, and making notes about the process. (done-ish, in Tracker)
• I'll update workingenv.py to use (optionally) --home instead of --prefix, which will make Zope much happier. (done: ticket updated; works much more smoothly)
  
• Make sure I have any accounts I'll need. (I think Scott has set me up with everything: email at ianb at openplans, traffic unix account, svn account, and I already had a Zope account)
• Figure out what it takes to get WSGI middleware in front of Zope. Any middleware at this point, just to see what it's like. Probably using the zope.paste package. This is the inverse of Zope->WSGI, but would be used for something like theming.
• After the discussion with Sidnei, I feel ready to give a go at the Zope/WSGI stuff (both ends), and set up a project topp.zwsgi. No code yet, just the project layout.
  
• Maybe do some work on wphp (WSGI->PHP gateway).
  
• I have a bunch of notes and ideas to write up, which I'll put up on this site.
  

• Chatted with Sidnei da Silva some...
• He says Zope 2.9.3 definitely doesn't have the WSGI stuff in it (zope.app.wsgi isn't live code in 2.9.3), and 2.10 probably won't, so it's deferred to 2.11
• Though Lennart Regebro would know best about the state of WSGI in Zope
  
• Anyway, I'd rather not even wait until 2.10, and this has to work with Plone, so that would mean 2.10+whatever time it takes to make Plone work on 2.10
  
• ZPublisher.Publish is where the publishing starts, specifically the publish() function.
• mapply() in that publish function is where a given object gets called -- the object on the other end of that function would be the WSGI application (or, rather, a Zope-specific wrapper around some WSGI application). This would allow us to embed WSGI applications into Zope.
• You could call publish() to start a Zope request. Which means, a WSGI filter/middleware could call that function.
  
• ZServer.HTTPServe is where the request (that is passed to publish()) is created, in continue_request of the zhttp_handler. To embed Zope in WSGI, we'd need to create the request object from the WSGI environment.