As for naming, can we fork a new branch of the codebase, and retain backward compatibility by using the same inlets / outlets (arguments ) as the old objects so there’s source level compatibility in Max patches?
Can rewriting the zeroconf to use Max SDK threading be transparent to the Max coder who invokes the zeroconf object?
We could start inventing new series:
sc.zeroconf.*
…I suppose, to more clearly mark this new era. But it seems less principled software engineering :)
Xin Wei
_________________________________________________________________________________________________
On May 21, 2015, at 9:13 AM, Todd Ingalls <TestCase@asu.edu> wrote:
Hi
The networking infrastructure of much of the tml code relies on zeroconf object which allows one to publish services such as osc streams which others can discover. it is a nice mechanism but the objects currently have problems when listening for services on a local wired network while also having wireless on. This means the computers used to run the system have no external network connection. I have modified them to be able to listen to only a selected network interface but I have come across another problem and that is there is some compatibility between the current Max SDK and the threading code in the objects which cause them to crash max when the objects are freed. Since they do not sue the Max SDK threading api they should probably be switched to that. I am willing to put that work in because it has been 4 years since the original objects have been updated but it does bring up some questions for me. For sustainability of SC how much effort should go into objects that are not being actively updated/fixed by others (for instance, was this the best choice without having someone who could update objects if necessary) and secondly what do we want to cal objects written. i could simply call the new objects zeroconf2.* or do we call them sc.zeroconf.* or some other convention.