[nanomsg] Re: New release?
- From: Drew Crawford <drew@xxxxxxxxxxxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Tue, 28 Oct 2014 01:59:06 -0500
I’m using native code on the client.
I haven’t actually thought through how to handle the browser in any level of
detail, but I would probably set up a REST-to-nanomsg proxy for the common
path. However REST doesn’t map well to some nanomsg protocols (pubsub I’m
looking at you) so I’m not sure it’s realistic to support the full featureset
of what I do in the browser. It’s possible that a WS transport would make
sense in those cases, I really haven’t give it much thought.
> On Oct 28, 2014, at 12:47 AM, Garrett D'Amore <garrett@xxxxxxxxxx> wrote:
>
> Don’t you wind up really needing a Javascript implementation though? Or is
> your client running native code? (Not in a browser, I hope!) (Death to
> ActiveX controls! :-p)
>
> - Garrett
>
>> On Oct 27, 2014, at 10:03 PM, Drew Crawford <drew@xxxxxxxxxxxxxxxxxx
>> <mailto:drew@xxxxxxxxxxxxxxxxxx>> wrote:
>>
>>
>>> On Oct 27, 2014, at 12:53 PM, Garrett D'Amore <garrett@xxxxxxxxxx
>>> <mailto:garrett@xxxxxxxxxx>> wrote:
>>>
>>> I think a more natural architecture is to develop applications that speak
>>> REST or something like it, and have middleware that “translates” between
>>> nanomsg and REST. (Put another way, I see most of the value of nanomsg and
>>> also zeromq in back end plumbing, with little real use for it in
>>> facilitating communications with individual clients.)
>>>
>>> That said, I’m sure others have use cases for it.
>>
>> Just wanting to go on record that nanomsg-to-clients is the entire use case
>> for me.
>>
>> On the backend, there are a lot of options: RabbitMQ, ZeroMQ, etc. My
>> personal view, is that I’m not convinced nanomsg improves in enough key ways
>> that I would select it over those alternatives, in a vacuum. I realize I’m
>> in the minority on that, but that’s my view based on the kinds of use cases
>> I have.
>>
>> The frontend case, however, is a different story. I know that this mailing
>> list is full of more than a few complaints about its use in clients from me.
>> And I think if somebody set out to create a library targeted at that
>> problem, they could do a better job than this. However nobody has done
>> that, and as far as I’m concerned nanomsg does a much better job than any
>> actually existing alternative. So much so that is easier to bend nanomsg to
>> my will, and then vent about it here occasionally, than anything else.
>>
>> Obviously if REST can work for your usecase, then use that. But if you’re
>> looking for a REST client, I don’t know how you ended up on this list ;) If
>> you are here, then you are doing something where REST won’t work for
>> technical reasons.
>>
>> nanomsg is a reasonable way to quickly prototype various REST-like (or
>> unlike, for that matter) alternatives, and swap them out without much
>> changes to application code. There is a lot more work to be done on that
>> front, but from my chair even that is a milestone no other library has
>> achieved quite as well as nanomsg has. And that makes it uniquely suitable
>> for client problems.
>>
>> Drew
>>
>>
>>
>>
>
Other related posts:
