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. 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. Yes, spreading FS across [power of 2 size] segments should eliminate holes and more complicated bookkeeping for large arrays. Eddie
