Plan

baseid/uuid

For later:

• ( ) intid specialization
• ( ) create branch for intid in zope3 svn repository and checkin baseid/intid split and alert zope3-dev to branch and uuid as a separate use of baseid (requires commit rights by derek)

Outbound

For RC1 (released to cheeseshop October 12, 2008):

• (√) (Derek) Make sure vice plays nice when the eggs are in a buildout but it hasn't been installed

• (√) (Matthew) Make sure vice can be uninstalled 
• (√) (Paul) Fix the KSS validation bug on feed configuration
• (√) (Alex) Documentation on extending with new adapters and templates
• (√) Issue #4 - print local url for feed in feedconfig grid
• (√) Verify setup.py metadata is just right
• (√) Tag releases and remove setup.cfg files
  
• (√) Create eggs and release to cheeseshop
• ( ) Fix cheeseshop entries to include short and long desc
  
• ( ) Release to plone.org
• ( ) Announce!

For 1.0-final:

• ( ) 100% test coverage. See p4a-test as an example.
• ( ) Make tests run faster so that people aren't deterred from contributing.
  
• ( ) Address fschulze's 2007 SoC comments
• ( ) eliminate 'XXX TODO:' markers for non-app package
  
• ( ) eliminate WARNING messages at Zope startup for non-app package
• ( ) Write tests for portal_syndication's replacement to make sure things that rely on the old version don't break
• ( ) refine migration - eliminate TODO markers

• ( ) polish/refactor doc tests - make sure we explain how to use and extend - i.e. README.txt
• (√) add zope3 dependencies to v.o? this would require the use of affinitic.recipe.fakezope2eggs in all zope2/plone buildouts. but it allows testing on zope3
• ( ) Change the buildout to use the zope2install version of fake eggs rather than standalone
  

For later than 1.0-final:

• ( ) Split vice.outbound into vice.outbound.core, vice.outbound.config, and vice.outbound.uuid
• ( ) Change vice.outbound.uuid to depend on vice.outbound.core instead of vice.outbound.config
• ( ) Provide a plugin for the published_url field (local utility lookup) to provide customizable defaults for the field. May require extending formlib to have dynamic calls of functions at form render time to get defaults - a lack I've been bemoaning for a long time!
• ( ) Feed for individual content items and feed entries for versions
• ( ) atom views for individual items
• ( ) Add 'required permission for use' entries to the feed format tuples. This will allow customizers to provide feed formats that are usable by some people and not others. One use case is mine: I'll be using Vice to provide specialized feeds for synchronizing content over multiple web sites and I don't want 'regular users' to be able to create them. Another use case is pbugni's, where, if I understand correctly, he's doing basically the same thing. The default for the feeds shipped in p.a.s.o will be something easy like 'plone.syndication.viewfeeds' (or however it's spelled). Thus normal users and admins will never know it's there and it's only the deep customizers who need it who will ever encounter it. This intersects with the dynamic feed feature above - you won't be able to get a dynamic feed for a format that you don't have permission to add normally.
  
• ( ) dynamic feed config settings via url params - example: http://site/folder/feed?format=atom - don't recurse because of DoS potential

• ( ) Pre-populating feeds. It's a hassle to populate feeds on every container, especially if you just want the standard three, non-recursive feeds named 'Atom', 'RSS 2.0', and 'RSS 1.0'. So, we should pre-pop them in the feedconfigs when the syndication tab is first accessed and the annotation created. Make the three default feeds enabled individually, but disable feeds for the container as a whole. Thus, to get the three standard feeds, just click the Syndication tab, check Enabled, and click Save/Apply. It can't get much easier than that (and, if you do want it easier, that's what the dynamic feeds are for :) ). It would be nice to make the code that creates the pre-populated feeds a pluggable utility, so that others can override if they want a different set of pre-populated feeds.
  
• ( ) itunes format

from wooda's basesyndication impl, it looks like itunes is just rss 2.0 + a namespace declaration and itunes:author, itunes:summary, and itunes:category on each feed item - cake! confirm with wooda and read the spec at http://www.apple.com/itunes/store/podcaststechspecs.html

• ( ) bridge product for p4a
• ( ) Create an interface that, if provided by an object that provides IFeedable, disables recursion. This gives fine-grained control for sites that don't want to turn off the option entirely. And it makes good sense when making classes that never contain child containers IFeedbable. I ran into this tonight with Quills, where it makes no sense to have a recursion option for Weblog objects.
• ( ) feeds that are tag-specific. this is necessary for integration with quills without losing current quills feed functionality.
  
• ( ) integration with quills via quills.syndication
• ( ) vice.zope3.outbound
• ( ) megrok.vice.outbound
  
• ( ) ?use entry points for registering selectable syndication options?

Inbound

• ( ) implementation for ZODB side of inbound AJAX solution; attributes needed for inbound feed: {title, URL, number}
• ( ) view class for setting inbound feed attributes

• ( ) Viewlet to expose inbound AJAX feed

• ( ) AJAX implementation (using what is found in research or home rolled if necessary)
• ( ) Non-AJAX inbound syndication design session

• ( ) Non-AJAX inbound syndication

All packages

• ( ) Add the --coverage flag to our test calls, and work toward 100% coverage. See p4a-test as an example.

Ideas

• gdata
• ical, vcal