From:	(Justin Mason)	Date:	Wed Jan  3 08:38:59 2007
Subject:	Re: [PATCH] Advanced tagging and filtering

Malte S. Stretz writes:
> On Wednesday 03 January 2007 13:02 CET Justin Mason wrote:
> > hi Malte!
> >
> > Thanks for this, it looks very useful indeed.  One tweak, though:
> > > b)  Makes the TAG part of the filename configurable.  Ah, yeah, TAG was
> > > called HASH before :)  I added the parameters tag (static tag), tag_sub
> > > (callback to generate a dynamic tag) and two more (tag_max_length and
> > > tag_warn, cf. inline doc).
> >
> > I would prefer to *add* the TAG part *as well as* the HASH stuff.
> > The hash is useful, since it avoids collisions -- TAG doesn't make
> > that guarantee (nor should it have to).
> >
> > That should be OK, right?
> 
> Yeah, that was my original plan.  But I wanted to keep the filename format 
> backwards compatible.  Not sure if thats really needed, I also wasn't sure 
> if I should add the tag in the front, the end or in between.  In the end I 
> went for compatibility and assumed that in most cases the tags will still 
> be quite unique -- at least in the producer/consumer case where you've got 
> most probably some kind of pid in there they will be at least as unique as 
> the current hostname/pid based ones.  And if not, we've got the timestamp 
> plus the additional really random part at the end :)

backwards compatibility is not a problem here, so go ahead and
add the tag in addition to the hash.

I think the best location is just before the hash, e.g.

    50.20040909232529941258.TAG.HASH[.PID.RAND]

(vs the simple

    50.20040909232529941258.HASH[.PID.RAND]

when tags are not in use.)

> Actually, when people start to filter the files based on their name, the 
> format must not change anymore in future.  Maybe the filter should apply to 
> the tag only...

Yes, I think that's a good idea... people shouldn't have to worry about
the rest of the filename changing.

--j.