gdiethelm at dcv.cl
Wed Jun 9 19:00:08 CEST 2010
> > I agree wholeheartedly. I think the timing functions should stay and
> > supported portably across platforms.
> > There is/was also a zmq_sleep() function in there. Will it be kept?
> > Should it?
> I don't think that is needed.
> > At some point I also proposed adding a zmq_uuid() generation
> > but it was decided it was beyond 0MQ's scope. Perhaps we could come
> > with clear cut criteria for what kinds of functions belong in 0MQ.
> I do agree with Martin that 0MW should not become a portability
> library. In short, we need some other reason to include something in
> the API. For the case of timing, that additional factor is
> timing/benchmark uniformity and consistency. I don't see what that
> additional factor is for zmq_uuid, so I would tend to say no.
Just to clarify, I was not proposing (again) to add this function;
rather, I was providing it as an example of a rejected function
according to criteria that perhaps should be clarified. I agree with you
that zmq_uuid() should not go into 0MQ.
More information about the zeromq-dev