[tahoe-dev] patch review

Brian Warner warner-tahoe at allmydata.com
Thu Jan 8 01:30:32 UTC 2009


>  > [3292]: http://allmydata.org/trac/tahoe/changeset/3292 "refactor
>  > some common logging behavior into mixins":
> 
> If there is an original parent (self._parentmsgid is not None), then
> they will be.  I agree that the use of self._parentmsgid is ugly, but
> it seemed that this is how our code was using logging -- emitting an
> initial message like "startup" and wanting all subsequent messages to
> be children of that initial message.

Hm. I think the way I did this before LogMixin was to emit a master log
message in __init__ (like "Download Starting"), stash its number in the
object, then have the local log() method use that number as a logparent
unless the caller provided something more specific. In the LogMixin world,
that would correspond to adding a line to __init__ that looks like:

  self._parentmsgid = self.log("Download Starting", parent=self._grandparentmsgid)

I guess I wouldn't advocate changing it. In my previous style, if I forgot to
do that "master log message", then (assuming I'd remembered to set
self._parentmsgid to None somewhere) all the log messages would be
unparented, so in the web-viewer they'd get sorted all over the place, and
it'd be hard to see that they were related at all. In your LogMixin code, the
consequence of not providing some 'master' event is that the first emitted
message gets used as the master event, and all subsequent calls become
children of that one, which puts them all in a single place. (I was
mistakenly thinking that three successive calls would result in three
generations of events, but since self._parentmsgid is only set once, you'd
only get two generations).


>  > [3326]: http://allmydata.org/trac/tahoe/changeset/3326 "storage:
>  > accept any size shares"

> So, I think we should ... just advertise "available space on this server"
> as the effective share size limit, as in your first suggestion above.


Ok, cool, I've updated #569.


thanks,
 -Brian



More information about the tahoe-dev mailing list