If we are thinking of Delta CAS in the context of service the largest xmi id works. But we were also using the same mechanism to support tracking CAS activity by component. I suppose in the second case the additional overhead of maintaining a list of the FSs that are added may be acceptable.
On Wed, Jul 9, 2008 at 3:48 PM, Adam Lally <[EMAIL PROTECTED]> wrote: > > Back to the high-water mark ... isn't it just the largest xmi id in the > > serialized CAS? Its relationship to the CAS heap is a matter of > > implementation but presumably we can have a design that says any new FSs > > must be given an xmi id above the high-water mark when serialized back > from > > a service. We already have the requirement that ids must be preserved > for > > the merging of parallel replies. > > > > Yes - there are really two definitions of high-water mark floating > around in this thread and it would be good to split them apart. > > (1) the largest xmi:id in the serialized CAS. This is a requirement > that the service protocol places on the CAS serializer. This is what > we already have for merging, and I don't think Thilo is objecting to > this. > > (2) a dependency on the FS address being an indicator of which FS are > newer than others (an FS with a larger address is newer). > > As I think about it now I am actually unclear on whether we are doing > #2 right now at all. Bhavani said we were, but that's not how I > recall that the serializer currently works. It keeps a table of all > the incoming FS, which is necessary in order to have the xmi:ids going > out be the same as the ones coming in. So I thought the serializer > just used the fact that an FS was missing from this table to determine > that it was new, and *not* a high water mark of the FS address. > Bhavani, can you clarify? > > -Adam >
