On 10/18/07, Thilo Goetz <[EMAIL PROTECTED]> wrote: > > > Perhaps "requirements" was the wrong word here; "opportunities for > > improvement" would be better. The envisioned implementations have no > > dramatic impact on existing design. But as long as we are discussing, > any > > comments? > > > > Eddie > > > > If by "existing design" you don't mean CAS internal > implementation details, that's fine with me. I'm > personally not very interested in sending XML serializations > of the CAS around the network. If what you're proposing > affects my ability to change the CAS implementation, > then I will have some comments. > > --Thilo >
As far as I know, the main requirements for delta CAS is that it is easy ( i.e. cheap) to know, 1. which FS were created in the current call 2. which preexisting FS were deleted from the index 3. when setting a feature value, if the containing FS was preexisting Another thing to keep in mind for calls to remote services is the requirement that any FS references in the client are still valid after making a call. As for impact on binary serialization performance, an easy experiment would be to modify binary serialization to end up with a string list instead of a string heap, using a scenario that had a lot of strings in the CAS. This would give a good idea of the extra overhead of creating individual FS objects. Eddie
