|
Saturday, January 11, 2003 |
|
Moving Toulouse Industrie Toulouse has moved to A new home (toulouse.amber.org) and a new publishing system. Most of the archives will be there soon. The Radio site will remain up indefintely, but no new content will appear here. 12:24:27 PM blips[] 
|
|
|
Saturday, January 4, 2003 |
|
Zope 3 reStructuredText Document 0.1 With Zope 3X alpha 1 out, I decided it was time to jump in again and see how it would be to write a new content object for it with associated components (adapters, views). I've tried to include comments in the files and README to document what I was doing as I was going along. It can be downloaded here, and requires a fairly recent docutils and of course Zope 3X Alpha 1. The current release is intended to focus more on documenting how to write a new content component for Zope 3 than on being a smart reStructuredText client. That functionality may come later. I have some other thoughts about the process posted on ZopeZen. 11:53:11 AM blips[]
|
|
|
Sunday, October 27, 2002 |
|
FDoc I've been asked recently about this FDoc project I keep mentioning. Today, I wrote a new document about it.
2:47:53 PM blips[]
|
|
|
Tuesday, October 8, 2002 |
|
On .Mac, part 1.3 - availability wrap up Without going into too much details, tonight after mad birthday celebrations (where I spent too much time being tired drunk instead of too-much-dancing drunk), I came home to an email from Apple concerning the .Mac outages. Their claim, which I believe, is that there have been equipment problems. They claim the vendor has not been able to promise no more problems in the future, and work is underway to install new equipment. Hopefully this works out well for them and for us subscribers, and it's nice to be notified. In the past, when the service was free, I didn't mind outages and interruptions, but as web services get integrated more and more into desktop applications and environments, service availability is going to be a critical issue. Hopefully having paying subscribers will offset the high cost of service availability. Large scale web services like .Mac, whatever Microsoft .NET My Services morphs into, and other large offerings require more than just a single web server sitting in California. Backup, caching, and location issues abound for service providers. Even Userland's Radio servers have had problems in the past (but have run smoothly now for months). Other services, like LiveJournal have also had availability issues, and in fact LiveJournal is closed to free accounts that don't come in off of a referral.
There are some other weblogs about Web Service Strategies that have better details than I can offer about the aspects of web services beyond SOAP, REST, or however the basic protocal is spelled for you. |
|
|
Monday, September 2, 2002 |
|
A Zope 3 story - augmenting other components It's very late, so I'll try to make this quick and write up more later. Today, I finally had enough free time in my coffers to download Python from CVS (aka - 2.3 pre-alpha) onto my old iMac, and augment that with Zope 3 - the ComponentArchitecture project. Then I installed the simple but usable Job Board Example. I soon noticed that said JobBoardExample was missing out on a couple of things - an editing interface, and an XML-RPC interface.
One of the notions of Zope 3 is that it's supposed to be easier for developers to embrace and extend other components by being able to write new "views" for them. So, I decided to write a JobEditView. I made a new Product (esentially, a plain Python package) called JobBoardEditor, and filled it with a couple of files - EditJobView.py, edit.pt (the page template to edit a single job with), and configure.zcml, the configuration file that ties it into the Zope system. It wasn't long until I could go to a Job object and traverse to my new edit form, and then have the submit go to my 'edit' method. But, at this point, I'm running into security issues that are beyond my measure to figure out, especially at 1:00 am with a beer headache. My other thing to try out was putting a simple XML-RPC interface on to the JobList. This was particularly interesting to me as I've found that while traditional Zope method calls should - in theory - work fine with something like XML-RPC, they seldom do. Sometimes it's because too much HTML is returned from a call, but most of the time lately (for me at least), it's that I want the server to do some processing of the results before sending them out to the client, using the relatively simple data types afforded to XML-RPC. As a result, I've been adding in extra Python Scripts particularly for XML-RPC, and letting them work in the proper places either via acquisition or some other clever tricks. It's not a bad system, but it's not exactly formalized or repeatable, since it's not in a formal Product. In Zope 3, this is different. I wrote a simple XMLRPCView class. 'View' objects in Zope 3 have two state members - 'request' (the incoming request object), and 'context' - the object the View is applied against. So, for me to add in the new functionality whereby I could just get a list of approved Job titles, I wrote the following Python file in my JobBoardEditor product:
from Zope.Publisher.XMLRPC.XMLRPCView import XMLRPCView
from ZopeProducts.JobBoardEx.IJob import JobState
class JobListXMLRPCView(XMLRPCView):
__implements__ = XMLRPCView.__implements__
def listJobTitles(self):
joblist = self.context
job_ids = joblist.query(state=JobState.Approved)
out = []
for jid in job_ids:
out.append(joblist[jid].summary)
return tuple(out)
Then, I added the following to
<xmlrpc:view
name="joblistmethods"
for="ZopeProducts.JobBoardEx.IJobList."
factory=".JobListXMLRPCView." />
With this configuration statement, I've added a new View to be published on the XMLRPC channel (which in Zope 3 runs on a different port than normal HTTP requests, which is probably wise) for objects that implement the IJobList interface. I was able to do all of this outside of the JobBoardEx product. I just had to ensure that the Product was added in after JobBoardEx by using the site's products.zcml file to affect the ordering. After restarting Zope 3 (which is a very slow restart on this machine), I was able to do this:
Py$ s = Server('http://localhost:8281/zoo/joblistmethods')
Py$ s.listJobTitles()
['test test test']
I actually had created two jobs through the web interface, but had only approved one. So I ducked in to the web interface to approve the other job, and then made the call again:
Py$ s.listJobTitles() ['test test test', 'the other job'] So, what are some benefits of this? One that comes to mind is issue trackers. Earlier in the day, I was writing a Python script to farm through some Tracker data and format it nicely for XML-RPC, with the intent of writing a simple AppleScript Studio application to list pending/accepted Tracker issues. I did this informally, dropping a Python Script into the folder above a particular tracker. Ultimately, it didn't work - and I think a lot of the blame goes on XML-RPC's utter disregard for semi-proper security. Since Zope's always published objects on the web with regards to web security standards (or embarrasments, depending on your view) such as 'Basic Auth', it's had problems with the "security by passing in arguments" design of many XML-RPC API's. But the point I was really going for was packaging. Even if the Tracker Issue finding Python Script had worked over XML-RPC, now I have to find other places to put it by copying and pasting it, ultimately adding another name onto an ever growing namespace. With Zope 3, however, I could write an XML-RPC view particularly for the application I was designing as a normal Python component, and install and configure it as necessary (and hopefully that configuration work will be better than copying and pasting plain Python Script code). I can name it specially, essentially adding a new namespace for my application. I can distribute it to other users fairly easily. Another example would be implementing the Blogger API not as a new weblog product for Zope, but as a view/adapter component that publishes on the XML-RPC channel, and communicates with other Zope components, either built in ones or third party. In summary - my first tangible Zope 3 experience in quite some time has been hopeful and helpful. There's still a long way to go, but the kernel is shaping up nicely. The pattern driven / Extreme Programming sprint driven development has yielded a decent - but still shifting - code base that should be stronger and simpler than Zope 2. Sometimes, there are enough levels of indirection in Zope 3 to make it look more complex, but so far most code has been easier to follow and trace than Zope 2 (although there are a number of empty folders/packages that probably need some brute force removing from CVS) - at least, it's usually easier to tell what's going on (and even this has an at least - at least, once you start learning the new paradigm). Zope's ancester, Bobo (the kernel on which Zope is still based), was all about abstracting the means of publishing an object on the web away from the object itself. Bobo, and then Principia / Zope 1.x, built upon this, but primarily in a single-UI / single protocol type way. It's obvious today that there are many ways of looking at things on the web, including never actually using the web itself. Zope 3 brings us back to the notion of an object publisher being able to serve up objects on different protocols. Zope 2 offers this today, but there is great difficulty in making WebDAV, normal HTTP, FTP, and XML-RPC all live harmoniously in the current design.
And finally, Zope 3 should yield a usable scalable means of adapting the works of other developers into new solutions by providing better control of product/service/view configuration and overrides, such as adding a new XML-RPC API to someone elses bug tracking system without having to alter that bug tracking system, or use secret Python hacks to alter behaviour. |
|
|
Monday, June 10, 2002 |
|
Organization Objects Ken Manheimer has also posted a proposal (a little bit dated) about what he calls Organization Objects, and a really good companion paper about the motivations for organization objects. The motivations paper discusses how the parent/child and table of contents relationship(s) were done for ZWiki, and how Organization Objects (which bear similarity to XLink) would have benefited the application. A bullet point in the Organization Objects proposal that I really liked is:
2:43:36 PM blips[]
|
|
ZWiki and logical structures. ZWiki is a sehr-cool beast, as far as Wikis go. A very attractive feature, seen all over the Zope.org web site is Ken Manheimer's work on page/parenting relationships. This makes it so that Wiki pages, although stored in a flat namespace (all in one folder) can appear to be hierarchical, depending on which page generated which page (parenting can be altered of course). This in turn leads to cool things, like a structured table of contents (see the Zope 3 wiki's TOC Here). It's especially cool in that it's fairly easy to change the hierarchical structure of the Wiki - by looking at a page's backlinks, one can reparent a page to one or more of its linkers. Essentially, new logical structures can grow independent of the physical structure. I've used a similar feature in a recent simple content system, wherein all documents were stored in a single folder, but the users entering content could classify documents in one or more categories. The main pages on the site were basically database queries (actually, catalog queries) based on the classifications. Thus, the site was built out of a simple logical structure rather than a physical one, which allowed documents to appear in more than one place if they needed to be. It's no unique concept, Radio and some other blogging tools allow this, much to my delight.
In the simple compound system I did for that customer, the flat namespace also allowed simple inter-document link management. The author could say "document A links to document B", and when document B was deleted, the link to it would also evaporate. For some reason, doing deep inter-object linking in Zope is still tricky business, but there's hope on the Zope 3 horizon (some of which looks like it may be backported to Zope 2). |
|
|
Wednesday, June 5, 2002 |
|
Intent, and human editable XML. There's been an interesting debate on the Zope 3 development list about ZCML - the new Zope 3 configuration language. The debate ultimately seems to be over what I view as "human readable" XML versus "machine friendly" XML. There is a lot of power and usefulness in XML, but the proliferation of namespaces and unknown attribute handling has taken the human out of it, I think. Intent gets lost. Anyways, they're sticking with the current ZCML format, which can be seen in practice here. It's not horrible, but it could be better.
Personally, I found the Servlet Web-App Descriptor to be much easier to work with, as per the Jakarta/Tomcat sample starter file. It's more verbose, which requires more typing (it seems that programmers really hate to type), but the intent is much clearer. Intent. It's valuable. But sadly, so easy to cast off. |
Last update: 1/11/03; 12:27:19 PM.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Home
Stories
Outlines
Neighborhood
Joy
Politics
Python
Zope
Mac OS X
Sound Design
EUCCI:
EUCCI Five Star
EUCCI Information
EUCCI Links
Reading:
Purple
Harper's
The Economist
The New Yorker
The American Prospect
Emigre
Eye
Surface
Wallpaper*
