> -----Original Message-----
> From: Jason Tishler [mailto:[EMAIL PROTECTED]]
> > Yes. I think that setup.exe based rebasing should be optional, but
> > default to on. A flag in rebase.conf to control this would be good,
> > along with a dialogue box and a tick :]. Not needed for the initial
> > merge though.
>
> OK, sounds good. I'm not a GUI guy -- I hope that Gary will
> come to my rescue. :,)
Ok, well lets get it into head, Gui can come later. (I can GUI too :}).
> > > I haven't tried LoadLibrary(), etc. but I presume that one of the
> > > APIs can. However, isn't this too little, too late?
> What can we do
> > > when the corruption occurs? Rollback to the copy in the archive?
> > > But, then this image will *not* be rebased. :,(
> >
> > I was thinking of the following process (for all dlls we attempt to
> > rebase):
> > 0) Check that it hasn't been rebased already.
>
> What is the purpose of the above? I already rebase DLLs into
> their previous space during reinstalls, if they still fit.
Efficiency, it seemed obvious to not rebase already rebased .dll's. I recall you
saying that it was fast, but I don't see it scaling to 100's of .dll's - which we are
heading towards.
> > 1) Copy
> > 2) Rebase
> > 3) Check for corruption - mark as occupying it's own prior space if
> > corrupt and then stop, otherwise mark it's new space in the
> used list.
>
> What happens when the prior space is already taken?
Good point. If the prior space is taken by a non-rebasable .dll (another thing to
record :}) then spit and error, otherwise, shuffle that dll to the next free slot.
> Is the "complete list" approach above required for the first
> iteration?
No. TODO lists are good. Give you something to do :}.
> > Ah. Well within setup io_stream is the answer as they
>
> Huh? You didn't finish the above sentence.
Something about, not sure what to do for non-setup version, perhaps link in
appropriate .o's.
> > What feels procedural is separate classes for
> serialisation. I _feel_
> > (And can there for be told to get my nose out of it) that a better
> > encapsulation would be for the used list and free list to have
> > [de]serialisation capability, and the config_file class to
> shrink to
> > simply finding the config file, identifying the beginning
> of (say) a
> > used list section, and then passing the buck. Would you care to
> > comment on this as opposed to your current model?
>
> Ah, I see your point. I guess that it depends on how you
> want to slice and dice. I have used the load/save paradigm
> many times before and in general prefer it. However, in this
> case I don't quite think of the config file data as object
> state. What happens if there are syntax errors, etc.? I
> think that a config file object should deal with these kinds
> of issues (although is could delegate some of the
> responsibility to the list objects). Additionally, with my
> current approach I can change the config file format without
> affecting the list classes.
But you can't change the list classes (ie add a new mandatory constructor parameter)
without breaking the serialisation classes. I think you want the Memento pattern for
this.
> Nevertheless, if you feel strongly, then I will change my perspective.
It's not about feeling. It's about understanding. I agree that having the
serialisation in the classes themselves is not great, as things get baggy. I hope that
you agree that having external classes that require access to private data (ie
config_file_writer) for serialisation is also not great because it breaks
encapsulation (friends don't always break encapsulation, but in this case, IMO they
do). The Memento class is designed to provide a solution to both issues.
> > I'm suggesting I get my stuff out of your way :}. Your code seems
> > traditional list based, which mine isn't (anymore), so your
> code could
> > generalise to be a list/map template.
>
> OK, sounds good.
I'll organise this shortly, and let you know when I do it. (After setup200202 gets
into production).
Rob