Martin, Erich,
Thank you. This conversation has been very educational for me.
On Fri, Apr 24, 2009 at 9:56 AM, Martin Sustrik <sustrik at fastmq.com> wrote:
> Hi Erich,
>> Thanks Martin for the great response and clarification! This email should
>> be reworked into an FAQ entry (or 3) or a wiki page or similar.
>>>> Good point. Will do.
>> I respectfully disagree. This statement assumes perfect knowledge of both
>> languages and the interface between them. In many cases a good interface
>> generator can incorporate arcane tricks and whatnot that are tedious and
>> ugly to write by hand. i have personally seen this when using pyrex to wrap
>> c libraries. I don't know if it is a case of my C/python extension-fu being
>> weak, or pyrex being awesome (most likely a combination), but the pyrex
>> generated interface was much faster and easier to read.
>>>> You are welcome to try. However, I wouldn't expect much improvent simply
> because the wrapper is so thin - there's very little to optimise there with
> the exception of the memcpy issue described in previous email. And I don't
> believe any code generator, however smart, would help with that one.
>> Have a function: register_serializer(serialize_func, unserialize_func).
>> Then send includes the following python equivelent:
>>>> if iserialize_func is not None: serialize_func(msg.data)
>>>> and an unserialize_func call on the recv side.
>> I don't know how useful such a thing would be in languages that don't
>> have decent introspection. If it can be made to work in all the target
>> languages, or even most, then it does make sense from an api user's point of
>> view. With ths register_serializer function I don't have to wrap zeromq send
>> and recv myself. (of course I still could).
>>>> This won't work in strongly typed languages (C,C++,Java). By coincidence
> these languages are main focus of the project :)
>> A tangent off of this: I've been wondering for a while why the decision
>> was made to include wrappers for certain very slow languages like python.
>> It seems to me that all the focus on efficiency and maximizing the use of a
>> big cluster, that python et al undo all of that.
>>>> Several reasons:
>> 1. Rapid prototyping.
> 2. High-perf system written primarily in C can still benefit from
> administrative components written in Python. With administration the
> performance is irrelevant. Ability to write/change code easily is much more
> important. (It would be nice to have Perl binding for exactly this reason.)
> 3. Even python can benefit from features like ability to handle thousands
> of connections at the same time, fast disk offload of messages,
> auto-reconnection as application fail and get restarted etc.
>> Martin
>-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.zeromq.org/pipermail/zeromq-dev/attachments/20090424/d29bbcd6/attachment.html>