Yeah, I'll have to think about this myself. One way would be to have a limited number of counters, allocated as special "primitiveAttributes" on MaObjectFiler. Requests are handled serially, so they could increment/decrement them as needed.. But I hope we'll find a more general approach than that.
As for the ReadStrategies; did you know the server already caches them for each session? So the data is only sent whenever the strategy is changed. Also, the data is farily minimal in size (for the purpose of performance), so its serialized form it isn't much bigger than a reference anyway. I'd proably like to see some performance measurements before making this more complex.. Thanks for stimulating discussion about these ideas! On 6/15/07, Keith Hodges <[EMAIL PROTECTED]> wrote:
Dear Chris, I have had a go at writing a some server side facilities, such as a server managed counter. I wondered whether you would be able to help me/tell me how I put persistence on the back of it. The counter example code is in http://mc.gjallar.se/ in the Q2-Server-Request project I was going to use this as a means of having server persisted read strategies as well, i.e. you do a servr request to get the named read strategy before accessing the db properly. Also you could then tell the server what read strategy to use by reference rather than by sending all the data. I have lots of ideas but for now it would just be useful to have the counters persisted in the db files so that they get backed up etc. many thansk in advance Keith _______________________________________________ Setools mailing list [email protected] http://lists.squeakfoundation.org/mailman/listinfo/setools
_______________________________________________ Setools mailing list [email protected] http://lists.squeakfoundation.org/mailman/listinfo/setools
