Making models instead of code gives remarkable leverage. However rather than make zproto a mandatory tool, I'd like to do what we do in CZMQ, which is to provide API serialization methods (like zsock_send/recv) which are compatible with the zproto serialization.
On Wed, Feb 4, 2015 at 5:35 PM, Ed Griffiths <edg...@sanger.ac.uk> wrote: > Hi Gregg, > > >> Hi Ed, >> >> EG> 1) language independance... >> >> This was another thing that made 0MQ very attractive to me when I >> found it. Multipart framing aids in this, as your point #4 makes. >> Zproto as a replacement will define protocols more exactly, which is a >> good thing, but it's also something new to add to your mix. > > We will certainly take a look at that. From my quick skim I like the sound of > tools that "take models and turn them into perfect code"....;-) > > I'll be out of job before I know it ! > > > Ed > -- > ------------------------------------------------------------------------ > | Ed Griffiths, Acedb/ZMap development, Computational Genomics Group, | > | The Sulston Building, Sanger Institute, Wellcome Trust Genome Campus, | > | Hinxton, Cambridge CB10 1HH | > | | > | email: edg...@sanger.ac.uk Tel: +44-1223-496844 Fax: +44-1223-494919 | > ------------------------------------------------------------------------ > > > -- > The Wellcome Trust Sanger Institute is operated by Genome Research > Limited, a charity registered in England with number 1021457 and a > company registered in England with number 2742969, whose registered > office is 215 Euston Road, London, NW1 2BE. > _______________________________________________ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > http://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
