[Box Backup-dev] Re: First official Win32 release
Ben Summers
boxbackup-dev at fluffy.co.uk
Sun Jan 29 12:17:36 GMT 2006
On 28 Jan 2006, at 15:54, Chris Wilson wrote:
> Hi all,
>
> On Sat, 28 Jan 2006, Ben Summers wrote:
>
>>> svn diff -r 336:340 http://bbdev.fluffy.co.uk/svn/box/chris/bb-
>>> save-state
>>
>> lib/common/Configuration.h
>> lib/common/Configuration.cpp
>> -- is this really necessary? Not sure this functionality should
>> be in the Configuration class, and I haven't noticed this used
>> anywhere. Please remove.
>
> No, it is used. Not to reload the config, but to check that the config
> has not changed since the archived state was written. If it has
> changed,
> the archive should be discarded.
I would prefer that this was stored outside the Configuration object,
with the code which needs to know maintaining it itself.
>
>> bin/bbackupd/BackupDaemon.cpp
>> -- how long does storing the config take? Might it be better to
>> do it when the daemon terminates only?
>
> I'd say it's better to do at the end of each run, when we're not in
> a hurry. During system shutdown, daemons have only a limited and
> system-dependent amount of time to clean up before being killed by
> the system.
OK.
[snip]
>> lib/common/Archive.h
>> -- Is CommonException/StreamableMemBlockIncompleteRead the right
>> exception to throw?
>
> Probably not. It looks like Archive.h was based on
> StreamableMemBlock.h. Would you prefer OSFileReadError, or should I
> create a new exception like OSFileShortRead, or FileEndedUnexpectedly?
Maybe just ArchiveBlockIncompleteRead?
>
>> I see a lot of similarities between Archive and Protocol. Using
>> Protocol with auto-generated definitions would catch coding errors
>> later.
>
> Not sure that I'm up to the task of converting it. Perhaps Gary can
> help?
I don't think it's necessary, and would need changes to Protocol anyway.
>
>> We need to have a TODO file which lists all the stuff which we
>> need to get done, eg tests for this.
>
> How about BUGS.txt?
Yep.
>
>> I will not insist that operator overloaded i/o is changed (but
>> feel free to do so). After climbing down on this issue wrt the
>> logging i/o, it would seem inconsistent to be stubborn here.
>
> Presumably refactoring it to derive from Protocol would fix that?
Possibly. But I don't think that's worth doing for this release.
Ben
More information about the Boxbackup-dev
mailing list