[nanomsg] Re: more updates
- From: Garrett D'Amore <garrett@xxxxxxxxxx>
- To: "nanomsg@xxxxxxxxxxxxx" <nanomsg@xxxxxxxxxxxxx>
- Date: Tue, 22 Apr 2014 07:38:59 -0700
An object based approach may work well for the protocols. But I think less so
for the transports. We want to allow users to specify an address and have the
transport instantiation done under the covers.
Sent from my iPhone
> On Apr 22, 2014, at 1:56 AM, Ondrej Kupka <ondra.cap@xxxxxxxxx> wrote:
>
> Hi,
>
>>>
>>> Is there any reason all the sps are in one package? It looks like
>>> you've built a generic framework for them to implement. It would be
>>> more idiomatic if you had something like
>>>
>>> import "bitbucket.org/gdamore/mangos/req"
>>
>> It would have been a nice idea, and it is actually what I wanted to do (for
>> the transports too!) But I had trouble making this work as well as I’d
>> like, because of circular includes. In particular, I want to register all
>> the *stock* protocols so that users don’t have to register them explicitly.
>> The problem I had with this is that:
>>
>> mangos/req would depend on mangos
>>
>> but mangos can’t register req in the core, because if it tries to import
>> mangos/req, circular imports and death.
>>
>
> Just a question - why exactly are these strings being used to get the right
> pattern and transport? I know that that is how nanomsg works and how ZeroMQ
> works, but I don't really see real advantages to this. Why don't we do it
> more let's say object-oriented? I am working on a project of mine, which is
> rather small, but it works in the following way:
>
> 1) There is a single broker process.
> 2) The broker process contains various services, which basically take care of
> various communication patterns as known from nanomsg/ZeroMQ.
> 3) Every service can be exported using N service endpoints (transports).
> 4) Client processes connect to the broker and use exported services via one
> of the available service endpoints.
>
> So basically the situation is very similar. Now what I did was to just define
> interfaces. Then you can import things as you want. But also I don't use
> strings to initiate things, I let the user import the packages for both
> socket and transport and bind them together in his code, so there are no
> circular deps. It's like
>
> import (
> "bus"
> "bus/tcp"
> )
>
> socket := bus.NewSocket(tcp.NewTransport())
>
> It is a bit different in reality, but you get the point. So I am just
> wondering why not to use objects instead of these strings and also let the
> user bind things together? It not only allows more compile-time checks,
> because the interfaces are defined, but also it solves the circular
> dependencies problem.
>
> Regards,
> Ondra Kupka
Other related posts: