<browser:viewlet
name="cart-actions" manager="Products.PloneGetPaid.interfaces.IGetPaidCartViewletManager" class=".cart.Actions" permission="zope2.View" weight="20" />

<plone:portlet
name="getpaid.cart" interface="Products.PloneGetPaid.browser.portlets.cart.ICartPortlet" assignment="Products.PloneGetPaid.browser.portlets.cart.Assignment" renderer=".cart.Renderer" addview="Products.PloneGetPaid.browser.portlets.cart.AddForm" />

What's the issue here? The issue is that, given the way it's currently designed, you can only have one checkout wizard known to the system at a time. In other words, you select which checkout process you want by only having registered the one you want.

Obviously, this is tawdry. What we want is to be able to have as many wizards registered at a time as we want, then have some other utility that selects which one should be used. That way, instead of having to ZCML-activate something like Google Checkout, you would go to the checkout wizard selector and select the one you wanted out of the perhaps very many that were available.

Okay, second issue: the .txt file says:

- The GetPaid order manager is not integrated with Google Checkout.

Google Checkout includes its own order management functionality. Although Google Checkout does have a rich enough API that these two could be integrated with each other. And there is already working integration with the Google Checkout Notification API.

The details of this are a bit more fuzzy to me, but I think that "order management" means "keeping up with which things are boxed, which are shipped, and which have been returned" and so forth. The idea here seems to be that, if you use Google Checkout and want to use its order management functionality, then you have to use Google's site to do so, because GetPaid can't read back from Google's records about the order's state to tell you where each order is in the shipping process.

This area is much more of a mystery to me; would integration be done on-the-fly (pulling from a Google API as you browsed orders in the GetPaid management backend), or would Google somehow call back to or alert the Plone site so that content items were paced through a series of state changes as the order was fulfilled? I can't tell at this point exactly what was imagined.

Okay! That's some bare technical detail; and it almost sounds like Chris's concern is mostly for the first item, which if true would be felicitous since that's the issue that's technically the most obvious to me.

I have a third agenda: I'd like to make it easier to decouple ZODB storage from the application logic. Looking over the code, it looks like whoever wrote this made the content objects inherit from Persistent and then went ahead and wrote many basic methods right there on the storage objects. If this were factored off, then GetPaid could be used on top of TurboGears objects or Django objects instead by simply marking them with an interface saying "this is an order object! use it!" or whatever.