[Google-SoC] RFC: A Blogging and (outbound) Syndication proposal

[Tim Hicks]

All,

I've just sketched out a proposal for blogging and outbound syndication, 
and would appreciate it if people with an interest in these things could 
take a quick look and let me know their thoughts.

I'll be AFK until Sunday evening, and will try to submit this, or 
something like it after that... unless anybody objects :).

Cheers,

Tim

p.s. On the mentor front, I think I'm reasonably comfortable with the 
weblog aspects of this project.  The guidance I'd be more likely to need 
would be Plone-ish and Five-ish in nature.  Therefore, if they are 
interested in things like this, perhaps someone like Alec, Whit, or 
Martin could be suitable.  Jon Stahl (whose name appears as a potential 
mentor for this project on the page put up by Nate) has already said he 
doesn't feel able to act as mentor.



Integration of Componentized Weblog Technology into Plone
=========================================================


Definitions
-----------

Five: http://codespeak.net/z3/five/
Flon: http://plone.org/products/plone/roadmap/104
basesyndication: http://svn.plone.org/view/collective/basesyndication/
fatsyndication: http://svn.plone.org/view/collective/fatsyndication/
ATCTSyndication: http://svn.plone.org/view/collective/ATCTSyndication/
plonetrackback: http://svn.plone.org/view/collective/plonetrackback/
qPingTool: http://projects.quintagroup.com/products/browser/qPingTool/
generations: 
http://svn.zope.org/Zope3/branches/ZopeX3-3.0/src/zope/app/generations/ 
(and later versions on different branches)
Quills: http://svn.plone.org/view/collective/Quills/

Motivation
----------

The motivation is twofold:

   1. To provide a compelling weblogging solution for Plone.  It is 
hoped that this will be useful in and of itself, but also as a way of 
attracting users to the Plone platform more generally.  (c.f. 
<http://theploneblog.org/blog/archive/2005/12/29/marketing-mindshare-and-blogging>).

   2. To provide publicly available example code for how to use the new 
patterns of development heralded by the Zope 3 project within the 
context of CMF/Plone.  Specifically, to provide an example of how to 
dynamically repurpose existing Plone content types using marker 
interfaces, adapters, and views so as to avoid the tendency for 
CMF/Plone solutions to be rather application specific.  "Subclass as a 
last resort"?


Proposal
--------

I propose to produce a series of componentized weblog technologies for 
Zope/CMF/Plone that allow arbitrary object types to benefit from the 
technologies that have made weblogs such a growth "industry" on the web. 
  Syndication feeds, trackbacks, simple archiving and display, remote 
authoring (MetaWeblogAPI, and friends),  and, potentially, more 
manageable commenting, are all facilities that would benefit Plone. 
Existing Plone weblogging products have a tendency to be rather 
monolithic - requiring the use of custom object types for things like 
the weblog itself, its individual posts, its archives, and sometimes 
even its commenting facility.  The result is a that weblogging is to 
some extent ghettoized in the Plone world, with 
competing-and-incompatible weblogging products failing to share code and 
features with each other, or indeed, with "core Plone".  This situation 
is to the detriment of all.


Implementation
--------------

Syndication
~~~~~~~~~~~

Refactoring of basesyndication/fatsyndication/ATCTSyndication to provide 
a slimmer, more thoroughly Plone-integrated (outbound) syndication 
solution.  While the underlying code for this is largely present (in 
various each of the products just listed), UI toggles are likely to be 
necessary to leverage this feature across standard (and other) Plone 
content types.

Trackback
~~~~~~~~~

Completion of the plonetrackback product that allows for trackback pings 
to be sent to and from arbitrary Plone content objects.  The 
implementation is already largely complete, with just unit tests and 
more complete integration with the CMF/Plone catalog required.

Weblog Implementation
~~~~~~~~~~~~~~~~~~~~~

First, provide a (Five/Zope3) view for Plone's standard "Smart Folder" 
content type that adapts to an "IWeblog" interface.  This would allow 
for the reuse of the through-the-web/through-the-Plone (TTW/TTP) 
configurable query facility of "Smart Folders" for the purpose of 
populating a weblog with feeds.  Each catalog ("brain") result would be 
used get hold of the real object, which would in turn be adapted to an 
"IWeblogEntry" interface.  Thus, the use of arbitrary (and standard) 
Plone content types as weblog entries would be made possible simply by 
providing adapters for each to the "IWeblogEntry" interface.  The 
implementation would provide such adapters for the "Page", "Image", 
"Link", "Event", "News Item", and "File" standard Plone content types.

Second, using the "Flon" code (now integrated into "Five"), provide a 
TTW/TTP facility to mark individual "Smart Folders" (and, potentially, 
any other content type) with an interface that causes the default view 
for the object to switch to a weblog-ish view based on the "IWeblog" 
interface.  Further, such a marker interface could/should cause extra 
object tabs (next to "Edit", "Properties", et al) to become available 
for the purpose of providing extra weblog-specific configuration 
options.  As "Smart Folders" (and whatever other type this technique is 
applied to) will not have schema fields for this information, I propose 
to store the data in "IAnnotations".

Third, provide a traversal adapter that allows such a repurposed Smart 
Folder use archive-by-date URLs of the form 
"[Smart-Folder]/2006/05/06/[weblog-entry-id]".  This is a standard 
weblog feature.  As an intermediate step, the implementation would also 
require the provision of a non-persistent WeblogArchive class. 
Instances of this class would be injected into the traversal path by the 
Smart Folder traversal adapter, and would then allow for archive listing 
views to be used on URLs of the form "[Smart-Folder]/2006/05/".

Fourth, provide a component-enabled tool/utility that allows for update 
pings to be sent to services such as Technorati.  This would be 
equivalent to the functionality offered by qPingTool, but implemented in 
a way that is agnostic to the object types that update pings should be 
made for (by using adaptation).

Fifth, provide content migrations for the "Quills" weblog product to 
this new framework based on the Zope3 "generations" framework.  In 
addition to the benefit of the migrations for an existing user-base, the 
idea would be to provide example code for the Zope2 world to take 
advantage of this approach to data structure changes.