Re: feedback on the 2.0 specs

Ryan Barrett wrote:
> hey all. i finally had a chance to sit down with the 2.0 specs and write up 
> some thoughts. i posted them on the discussion pages on the wiki, and i'll 
> include them here too. thanks for writing them up, will and blake!
> 
> http://pyblosxom.sourceforge.net/wiki/index.php/Category:2.0_Planning
> 
> general:
> 
> The [[Filestat and sorting specification]] is god. We should take a closer 
> look at support for programmatically creating entry lists and shepherding them 
> through the serving pipeline. The spec is the right start, but support for 
> other features, like flavour templates, is incomplete. Right now, plugins that 
> create entries programmatically often have to reach into PyBlosxom's internals 
> to get feature parity.
> 
> The "end of the year" goal is aggressive, especially since the req'ts are 
> incomplete. We should try to put together a more concrete list of use cases 
> and features that aren't supported now, but will be supported by 2.0. Each of 
> the individual specs does this pretty well, but it'd be nice to have a (very) 
> brief list of *concrete* use cases in the top-level 2.0 planning page.

Well, it depends on how extensive the proposed changes end up being.  Up 
till now, I've been the driver for most of the changes and I think I've 
implemented about half of the things I wanted to change already.

I'm up for pushing out the date, but I do want to draw a line in the sand.


> blog.ini:
> 
> I'm not familiar with Paste. Having said that, I think the proposal is great. 
> It's simple and mirrors the Python syntax.
> 
> My one question is is how syntax errors will be handled. Will unquoted values 
> be interpreted as strings? How about unquoted values in lists? I think either 
> failing fast or coercing them to strings would be fine.

I hadn't really thought about that.  I'll add some notes about the 
behavior when the syntax is incorrect.


> entryparser:
> 
> Have we heard from many people who want to keep their entries in databases, or 
> wherever, as opposed to on filesystems?
> 
> Just to clarify, right now, all metadata lines are required to be at the top, 
> right below the title? You can't have metadata scattered through an entry, 
> right? (If so, that's good. I wonder if we should even support it above the 
> title, but that's mostly subjective.)
> 
> What's up with the *#markup rst* metadata line? It seems to imply that entries 
> can "override" their extension and thus choose their entryparser and 
> pre/postformatters. Is that right? Is that supported now? Are you considering 
> it for 2.0?

One of the adjustments here is that I want to get away from the idea 
that file extension denotes formatting markup of the entry.  All files 
that have the PyBlosxom entry structure entries are text files and we 
should be denoting the format of the body of the entry in metadata 
rather than as the file extension.

This makes some things easier to deal with--all entry files that are 
structured like a PyBlosxom entry can end in .txt.

It also makes it possible to have formatters trigger for entries that 
come from other sources.  Entryparsers currently don't work for this use 
case at all.

Entryparsers will continue to be good for files that don't follow the 
PyBlosxom entry structure.  For example, if someone wanted their blog 
based on a maildir, they'd need an entryparser for that.


> Do you know if we have any users with very large entries? If so, I wonder if 
> streaming support would be interesting. If an entry didn't need pre/post 
> formatting, and we changed the entry parser calback signature, we could 
> support streaming entryparsers so that entries don't have to be loaded into 
> memory. Clients would also start seeing the page sooner.

This should be possible, too: formatters take a file-like object rather 
than a filename.  So then they can seek and fiddle around and then:

a) we don't have to load the whole file in memory, and

b) PyBlosxom works on things that aren't files (i.e. they can be 
StringIO objects or other objects that have a file-like signature).


> templates:
> 
> Hmm. This is a good doc, but I'm unclear on what's new. The only feature that 
> was new to me was scoping and function calls in variables. Is that a new 
> proposal, or is it supported right now?

At the moment, this is less of a "new things are coming!" spec and more 
of a "how the hell do templates work?" spec with some minor adjustments 
in behavior mostly related to scoping and function calls.

That part is new and is implemented already.

I also want to explicitly specify what variables are available and their 
semantics.


> plugins:
> 
> We should clarify that we'll include a few mature plugins *of our choice* with 
> PyBlosxom, as opposed to all mature plugins. Also, we'll only do it with the 
> plugin developer's permission, since we'd have to either take over 
> maintennance or add them as a committer on SourceForge. :P

Oo--I like that.

I'm also thinking when we add plugins to the registry we also grab them 
and put them into the sandbox.  That way if the plugin author goes away, 
we maintain a copy.  This adds a requirement that all plugins must be 
distributed under an open source license of some flavor...  but I think 
it solves some huge problems that we currently have.


> BTW, I'd never really paid attention to conditionalhttp before. Does it only 
> have a single, site-wide setting for Last-Modified, ETag, etc.? Does it set 
> them per page? I wonder how it supports plugins like comments that can result 
> in new content outside of entries.

I think at the moment that it's pretty basic and it applies site-wide.

Thanks for reading through the specifications.  I'll take some time in 
the next few days to factor your commentary into the specs I know most 
about.

/will

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/