New items added to openplans page. Still open for discussion, if anyone
feels a need.

Derek

On 10/23/07, Derek Richardson <syndication@...> wrote:
>
> 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
>