Hi, On Thu, 2007-10-25 at 04:01 -0500, Dirk Reiners wrote: > Hi Gerrit, > > Gerrit Voss wrote: > >> I'm currently thinking about how to handle the FieldBundles correctly > >> with the reference counting pointers that are now stored in Fields. > > > > just move the ref counting from the generated functions to your ptr > > classes. > > Well, the problem is more about what to do concerning internal/external > refcounts and the respective pointers, and about Parent pointers. Do the FBs > need those, too?
Just ignore this for now. They are only used internally right now so using your internal refptr is fine. All the rest comes later. > >> My understanding so far was that they do not have the multi-aspect > >> copies of containers, but are transported over the network for > >> clustering. However, that does not entirely match the code on trunk. If > >> that is indeed the desired functionality, but it just is not fully > >> implemented, how about doing it by creating FieldContainers where the > >> AspectStore holds a pointer to the same object for each aspect ? > > > > no, the whole thing is already confusing enough, so I don't think that > > approach is a good idea. > > Well, my main idea in suggesting that was to simplify things Hmm, my current feeling is that right now, with the ref ptrs as they are, we are heading in the opposite direction anyway. I'm still a little bit confused why you choose to do two different things at once, classic ref ptrs and changelist optimisations. Especially as the optimisation part causes all this internalptr stuff to come up in user space. I kind of still doubt that the ref ptr infrastructure really is the best place to do this. > and get rid of the whole FB hierarchy let me think about it a little bit. kind regards, gerrit ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Opensg-core mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-core
