Re: comment file naming

On Wed, 29 Dec 2004 00:47:39 -0500, Bob Ippolito <bob-Zl9L/[email protected]> wrote:
> 
> On Dec 29, 2004, at 12:12 AM, Bill Mill wrote:
> 
> > 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:
> >>
> >>> 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.
> 
> Yes.  If you wanted to have the filename also contain the name of entry
> so it might be easier to notice in an editor buffer, you could do that
> too... but I definitely think that partitioning the "commentspace" on
> the filesystem with directories named similarly to the entry they refer
> to is a good idea.  After all, "Namespaces are one honking great idea
> -- let's do more of those!" (see "import this").
> 

I forgot why I didn't want to do that - backwards compatibility. I'd
like to keep the comments on my blog, as would lots of people, I'm
sure. If I wanted to change the naming scheme in any significant way,
it would require users to convert their current comments or would use
an ugly hackish scheme to get around that. Since what we have works,
I'd like to keep changes incremental for now.

> >> 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.
> 
> The best practice is to use unicode objects whenever possible (read:
> str is evil).  You should ONLY use str as an intermediary at byte
> stream boundaries (files, sockets, etc.) when representing text.  All
> strings that represent text in source code should be u"strings".  The
> codecs module has sufficient (getreader, getwriter, etc.) support to
> wrap file objects with an encoding so read/write/readline and friends
> will deal in unicode objects instead of bytes.  Of course, sockets are
> another story if you're using a non-blocking interface, but the story
> is similar enough.
> 
> UTF-8 is the obvious choice for an encoding because it's typically well
> enough understood by tools, even if by "accident" because it is so
> similar to ASCII.  Other unicode encodings are either weird and obscure
> (UTF-7) or are multibyte (UTF-16, UTF-32, etc.) and won't necessarily
> be understood by legacy tools like grep.
> 
> I'm not sure what pyblosxom currently does for HTTP, but here is what I
> do, and it works with IE, Mozilla, Safari:
> - The "Content-Type" header should be "text/html; charset=UTF-8"
> - This should be repeated as a meta tag (for file:// urls, if nothing
> else)
> - form tags should have accept-charset="utf-8" method="POST"
> enctype="multipart/form-data" (not sure if enctype is strictly
> necessary)
> - There should be a <input type="hidden" name="_charset_" /> in the form
> - If the "Content-Type" of the POST has an encoding, or "_charset_"
> gets set, then use that when processing the POST.  "_charset_" should
> override anything else.
> 
> Useful links on the topic:
> http://lists.w3.org/Archives/Public/www-international/2003JulSep/
> 0036.html
> http://rf.net/~james/perli18n.html (see: "Q26. How can I i18N my web
> pages and CGI programs?")
> 

Bob, thanks a ton for this. It's exactly what I wanted. I'll be
digging into it tonight when I get home from work.

> snip

peace
Bill Mill
bill.mill at gmail.com


-------------------------------------------------------
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/