uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bhavani Iyer" <bhavan...@gmail.com>
Subject Re: Delta CAS
Date Wed, 09 Jul 2008 22:59:11 GMT
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
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 <alally@alum.rpi.edu> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message