I still plan to roll an alpha 2 ton Wednesday to put into user test.
However, working and thinking about Quills tonight has made me thin of some
more features and issues. Thus, I expect there will be an alpha 3 before we
close the gate on new features. So, if you can get your stuff in for alpha
2, do it and I'll appreciate it and be able to user test it; if not, then it
won't have to wait until Vice 1.1 or 2.0 or whatever feature release comes
next, so don't knock yourself out. ;)

Things I'm thinking about for alpha 3. I'm looking for feedback...

* dynamic feed config settings via url params - example:
http://site/folder/feed?format=atom - don't recurse because of DoS
potential. This will be enabled/disabled through the global configlet. I
think it's a really nice feature and I want it enough to implement it, given
time.

* Make the published_url field on the individual feed config hideable from
the configlet, to minimize user confusion on sites that don't need it. I'm
sure this will be a prereq for plone core inclusion - limi thinks our feed
config is too complicated for mere mortals.

* 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! Confronting users with a blank
field and no guidance is bad. On many sites that use published_url, I expect
it will be a standard url we can pre-populate and perhaps make read-only or
even hide it. But this may not make it in because it is especially hard. And
I mention that just because it will inevitably make pbugni choose to work on
it. ;) (Just kidding, Paul - you don't want this one).

Those three things are already on the list. New things I haven't put on yet:

* Put a setting in the configlet to enable/disable recursion. Currently it's
always a option. On some/many sites, they may not want recursion because
it's a potential performance killer. And this will help to simplify the
config screen further, which limi will like.

* 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.

* 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.

* 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.

So, that's seven features for alpha 3 that I see as the most interesting (I
haven't mentioned document feeds with version feed items because wooda's
already on that and it may be in alpha 2 :) ). Alongside side the
'features', I have one 'issue' that needs to be discussed and researched and
decided before beta:

* Upgrades involving GenericSetup. How do these work? Our current
GenericSetup profile isn't annotated with versions on the steps, so I think
re-running it will overwrite the established settings on the site? I'm not
sure, but even the possibility of that is *very* *bad*. I'm sure we'll have
future releases (like alpha 3, which hopefully will add some utilities that
will have to be registered, and alpha 2 or 3, which will have the
replacement syndication_tool for the zmi) where we'll need to add GS steps
to the profile. How do we do this without screwing everyone up? This is
*urgent* - more important than anythin else above. We need to solve it ASAP
(for alpha 2, if someone can - I wont' have time) to avoid disaster in the
near future.

So, comments? Claims to feature implementations? Pipe up, Vice Squad!

Again, I thank you all for being involved with Vice. I think things are
going great. The 1.0-final is going to rock! I know Vice is getting
over-engineered (I've got nothing better to do) but I think we're
effectively hiding the over-engineering for the base cases and providing
powerful flexibility for the edge cases. Easy things easy, hard things
possible ... wait, that's quoting the wrong language guru, isn't it? ;)

Derek