On Wed, 2 Jun 2010, Sarah Jelinek wrote:
So, back to the original question, should TI/Transfer -
a) provide alternate interfaces so that they can be called
directly from within a Checkpoint? Or, b) should a consumer (that is a
Checkpoint) of TI/Transfer
instead use the Checkpoint interfaces?
The advantage of (a) seems to be that it flows much better
for DC as the app whereas the disadvantage is that it can be viewed
as a violation of the CUD architecture in some ways.
The advantage of (b) seems to be that it conforms to CUD whereas
the disadvantage is that for some DC checkpoints that need to call into
TI/Transfer, the processing just becomes a little tedious.
I didn't realize this was the original question. It isn't clear to me why we
need to make an allowance for DC in this area.
Each checkpoint is a functional boundary. So, it isn't clear to me why a
Checkpoint would have to call directly into say TI or Transfer. If there are
really separate functional boundaries for DC then they need to be separate
Checkpoints.
I am arguing that some of these are just instances of TI and Transfer. So, as
part of the TI Checkpoint for a boot archive, it has to calculate the various
properties required to do this instantiation. The TI Checkpoint for a boot
archive is different than the TI Checkpoint for a zpool, and dataset, UFS,
etc... As part of an instance of this checkpoint type, it may have to do some
calculation to correctly instantiate the checkpoint.
Sarah and I talked offline and here's the gist
of our conversation -
In general DC should aim to conform to the CUD architecture
and the Checkpoints it provides. There are however exception
cases where certain DC checkpoints might need to invoke methods
provided by the CUD TI/Transfer checkpoints directly.
As I work on the DC design, I will evaluate what the various
DC functional boundaries (or Checkpoints) should be and list
out which of those Checkpoints need to call TI/Transfer
directly and why.
Alok
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
