Eddie Epstein wrote:
On Thu, Jul 10, 2008 at 5:30 AM, Thilo Goetz <[EMAIL PROTECTED]> wrote:
I would like to lift this discussion to a higher
level of abstraction, as Adam is trying to. What
are the actual requirements against the CAS? Here's
what I think I understood.
You want to be able to obtain from the CAS a marker
object. Then you want to be able to query the CAS
with the marker and an FS and ask if the FS was
added before or after the marker was obtained. Is
that right?
That's right, for a simple delta CAS reply from a service, but actually many
markers for journaling so that additions can be attributed to a specific
annotator.
Ok, I think that shouldn't make a difference.
Bhavani Iyer wrote:
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.
A requirement for delta CAS is to identity new FS and modified FS. A low
cost way to get modified FS is to add the FS-id to a simple list each time a
feature in a preexisting FS is set, then sort and remove duplicates. Being
able to identify and ignore new FS at setFeature() time allows huge
reduction in overhead because modifications are so much less frequent than
additions.
So you want to do this outside the CAS? Or not?
Yes, spreading FS across [power of 2 size] segments should eliminate holes
and more complicated bookkeeping for large arrays.
Eddie
