Re: comment file naming

On Tue, 28 Dec 2004 23:36:31 -0500, Bob Ippolito <bob-Zl9L/[email protected]> wrote:
> 
> On Dec 28, 2004, at 10:45 PM, Bill Mill wrote:
> 
> > I want to change the way that comments are named, but I also want to
> > solicit feedback from others before I do. All this comes about because
> > I'm writing a comment administrator plugin for pyblosxom. (it's not
> > yet in a usable state.)
> >
> > Currently, comments are named "<file comment attached to minus
> > extension>-<time of comment file writing>.<comment extension>". This
> > has several drawbacks. First, 2 comments on a single story cannot be
> > made at the same time (imagine a dual-processor machine, or 2 machines
> > writing to a shared storage medium) without undefined results. Yes, it
> > is unlikely, but certainly not impossible.
> >
> > Second, the date in the file name is used to sort the file entries.
> > While this is convenient, it puts significant meta-data into the
> > filename. Thus, changing the time of a post in such a way that
> > comments are correctly sorted involves renaming the comment whose time
> > has changed. Furthermore, the user is responsible for ensuring that no
> > two comments are set to have the same time, which seems a silly
> > requirement.
> 
> It's probably faster/smarter to sort by mtime, if you're going to do it
> by filesystem metadata.
> 

Good point. It's more pyblosxom-ish too.

> > So, if you agree that the naming scheme should be changed, how should
> > it be changed? I will be glad to code up a patch, but I wanted to ask
> > for suggestions on how comments could be better named - preferably in
> > such a way as to not break backwards compatibility. (This would
> > require changing the comment sorting to use the pubDate inside the
> > file, but I think this should be done anyway).
> >
> > My initial thought is "<file comment attached to minus
> > extension>-<randint(1, 100000)>.<comment extension>". The comments
> > plugin would simply have to assure that the file doesn't already
> > exist. Does anybody have a better naming scheme? Comments on this one?
> > Should the number be significant?
> 
> I don't see how this is better than using a timestamp.. you can resolve
> conflicts in timestamp just like you can resolve conflicts in random
> numbers - try something else.  The tempfile module is better suited for
> what you want to do, it already has the machinery to create a unique
> file with a given prefix/suffix in some directory.  There are other
> methods, but tempfile seems like the One Obvious Way.
> 

Yeah, I was thinking about that; however, I'd like a person to be able
to tell what story a comment is attached to by its filename. That
makes it easier for people who like to hand-edit their comments to see
what they're doing.

> Personally I would want to put comments in a directory if you're
> reorganizing things.

Oh, so your scheme would be something like
commentsdir/path/to/entry/blog_entry.txt/234593.cmt ? Seems to make
sense to me. This is why I asked for opinions.

> Using a prefix on the name is kinda weird when
> you ONLY care about comments in the context of a particular entry, no
> need to search a global "commentspace" when you could have a per-entry
> "commentspace" just as easily.
> 
> As for your reply regarding string encoding, I only have one thing to
> say: **U N I C O D E**.  utf-8 would be the obvious choice.
> 

Why would it be the obvious choice? All I know about unicode encodings
I learned from Joel on Software's article
(http://www.joelonsoftware.com/articles/Unicode.html), which is not
very detailed. Where does one read about these things? Yes, GIMF, and
I will research it, but I was mainly wondering if somebody could say
"Oh, I read this article and I understood python's unicode after
that"? The ones I've found so far are less than helpful in teaching me
the *architectural* issues around unicode. I think I get what the
encodings are, and what a code point is, but I want something like a
"python unicode best practices" guide.

Right now, the comments code writes out a character encoding, but it
doesn't seem to take this into account when it reads it in. I guess
I'll take this as an opportunity to get with the rest of the world and
understand unicode strings.

I already fixed a bug in the conversion to unicode, which may or may
not already be committed; I'll have to check. The comments code uses a
bunch of bare "except" statements, which makes errors hard to catch.
I'd like to try and change these into explicit except statements while
I'm in the code.

Peace
Bill Mill
bill.mill at gmail.com

> -bob
> 
>


-------------------------------------------------------
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://productguide.itmanagersjournal.com/