Re: thoughts on meta-data (was: importing entries)

On Apr 7, 2005 3:02 PM, will guaraldi <[email protected]> wrote:
> On Thu, 7 Apr 2005, Bill Mill wrote:
> >
> > Yup. If it's data, it should be in the entry - metadata should only be
> > accessible to pyblosxom, which may, in turn, give it back to the entry.
> > This is how my metatime plugin works.
> 
> I don't agree with that.  I think metadata is any data about the entry
> that's not the entry itself (i.e. the title and body).  I think it should
> be available to whatever wants to use it.
> 

How is it not available to everything the way I have it? It should be
inside the request object somewhere. I'm just saying that if it's a
direct substitution, it should be in the entry, not the metadata.

> 
> > Not true, check out the relevant lines of blosxom_file_handler. You have
> > a FileEntry object (which, admittedly, contains little other than the
> > filename and mtime):
> > <snip>
> 
> Whoops!  It used to be the way I described (I'm pretty sure, anyhow)
> because that's why I wasn't able to implement the sort callback.  I should
> have checked the code involved.  My apologies.

No worries, I think it changed when Robert (IIRC) added lazy file parsing.

> 
> Well, then.  I guess to fix these issues, we'd need to adjust the
> FileEntry as you mentioned so that it opens the file, pulls in the
> contents of the the file, extrapolates the title, extrapolates the
> metadata and leaves parsing the body until it's needed.

Yeah, I threw away the title in my pseudocode, which doesn't make
sense really. Maybe it would also be faster to store the number of
bytes already parsed, so that the actual entry parser could do an
f.seek() skip that many bytes of the file?

> 
> That actually (theoretically) simplifies a whole bunch of stuff:
> 
>    1) gets rid of the problem we have where metadata doesn't
>       get cached in the entry cache
>    2) gets rid of the problem where we have to implement metadata
>       parsing in every entry parser
>    3) fixes the "i want to set the mtime _IN_ my entry" problem
> 
> 
> > What entryparsers? I ask because I really don't know what else is out
> > there. If you were going to import from a DB, you would store the
> > metadata in seperate columns of the table where you kept the story - in
> > that case metadata parsing would be *blazing*.
> 
> I can't tell what you're asking here.  There are a bunch of entryparsers
> which take a file and parse it according to different markup rules.  So
> there's a textile entry parser, a Python entry parser, a moinmoin entry
> parser, a genericwiki entry parser, so on and so forth.  The blosxom entry
> parser comes with PyBlosxom.  There are a bunch that come in the
> contributed plugin pack.  I've seen a few other ones out there in the
> wild.
> 
> In regards to importing from a DB, I think that's a whole different can of
> worms since it has nothing to do with the file-based entry system we have
> now.  It's not real high in my list of priorities, but I do have a minor
> interest in enabling other people to do what they want to do if it's
> possible.

oh, ok, that's what the other entryparsers do. I really didn't know
what other entryparsers where out there, and it may indeed make a big
difference to them. I was just trying to imagine what else was out
there, and was thinking along the wrong dimension.

> 
> /will
>


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click