[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