On 09/02/2012, at 7:43 AM, Pieter Hintjens wrote: > On Tue, Feb 7, 2012 at 12:11 PM, Dave Duchene <[email protected]> wrote: > >> Why not add JSON and XML serialization for messages while we're at it? Why >> not have a configuration language for describing socket pairs? Because it >> complicates the library, and isn't needed for most applications. And *most >> importantly*, because the users of the library aren't asking for it. > > This is my opinion too, that change should be driven by demand, not > philosophy.
I do not entirely agree with that. The reason is: users have experience but no real foresight. Only people with experience with competing packages or theoreticians can have foresight. Users get stuck in tiny incremental changes, they get used to doing things "the One Way (TM)" and have little understanding of alternate over-views. Consider for example my own experience on the ISO C++ committee. Do you really think STL *replaced* the whole C++ standard library in one fell swoop based on everyone's experience?? Heck no! If the committee had been that driven by existing practice and user demand, C++ would have a woeful mish-mash of a library. What got STL into C++ was vision. We had a problem, a horrible library, and Stepanov came along -- he wasn't even a committee member -- and gave a presentation .. and the whole committee got seriously excited. The library design wasn't new as such, I believe there was an Ada implementation. But for C++ it was an entirely new concept and it just felt RIGHT. The decision to incorporate an entirely new and more or less untested design was (more or less) unanimous. There was hardly any demand from users. I mean how could there possibly be any demand for something that didn't exist yet? If I may, without offending anyone .. An American and a Frenchman are considering the new library. The American says "It works in practice!" And the Frenchman says: "Yes, but does it work in theory?" -- john skaller [email protected] _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
