Re: comment file naming

I don't have strong feelings about the naming of the files one way or 
another.  My biggest (selfish) concern is this:  if you are going to 
change the file name (by adding directories, etc) in a backward 
incompatible way, please do a conversion tool.  I have over 1400 
comments in the old style, and it would be a pain to switch them over.  
  Encapsulating filename generation in a routine would probably help, 
too.

As far as string encoding goes, I agree with Bob.  UTF-8 is the obvious 
choice.  In hindsight, I wish I had spent the extra time to learn more 
about Python's Unicode handling.  What's there now is just because I 
was lazy and wanted to get something working.

Ted

On Dec 28, 2004, at 9:12 PM, 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:
>>
>>> 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/
> _______________________________________________
> Pyblosxom-devel mailing list
> Pyblosxom-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/pyblosxom-devel
>
----
Ted Leung                          Blog: <http://www.sauria.com/blog>
PGP Fingerprint: 1003 7870 251F FA71 A59A  CEE3 BEBA 2B87 F5FC 4B42
This message is:  [ ] bloggable   [x] ask first    [ ] private



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