[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [sc-dev] Proposed new Buffer




On 20 Nov 2004, at 21:09, James Harkins wrote:

On Saturday, Nov 20, 2004, at 15:44 US/Eastern, Scott Wilson wrote:

*read and read now lack a completionMsg arg as they use this for the /b_info message.

Haven't done any testing on it yet, but I thought you were going to keep the original read method under a different name for people who who just want to use Buffer to manufacture allocRead messages for the server.


As I wrote: "As it is now you can avoid the overhead of the responder by using basicNew and msg methods, but a method could be added to create but not update automatically."

I thought I'd see if there was an actual demand for that. In most cases I suspect the overhead is not really significant.

In my readAndQuery method, there is a completion function that gets executed after the variables are updated. I believe there are some other classes in the main library that do something like this, so there is precedent. Might be a good solution here. Some of my classes depend on it, so your reworking would not be a complete replacement of my approach unless you put this in.

I thought about doing something like this, particularly in updateInfo. I'm not so sure about doing it in *read though, as this complicates the basic system for the sake of a special case. i.e. you'd either have to have separate OSCresponderNodes to update each Buffer, which is what I was trying to avoid in order to keep things simple and low rent, or you'd have to store the functions as well. At the moment one can add a responderNode manually and do that if needed.

But maybe you're right. I'll take a look at it.

S.