Eddie Epstein wrote: > 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
None of these are particularly easy to do now, and they won't be any easier or harder when I'm done ;-) As I said, there will still be unique IDs, and as long as you don't refer to the heap directly, my changes should not affect this design. > > 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. I must admit that I don't understand what you mean. > > Eddie >
