[nanomsg] Re: more updates
- From: Ondrej Kupka <ondra.cap@xxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Tue, 22 Apr 2014 17:49:40 +0200
I cannot exactly imagine what you mean with the protocols right now, haven't
read that much of the codebase. But even if I accept these factories based
around address scheme strings, the real thing I don't like is I guess that
everything is in a single package, which means that all the transports and
stuff are linked into the final executable. I see that there is this
RegisterFactory function that is called internally and can be called as well by
3rd-party packages so there is no problem in splitting the main package into
smaller packages which would call this function in init, as it is now. Just the
user would choose what to activate as kinda compile-time plugin. The import
circle can be always broken using either interfaces instead of structs or some
foo package holding common definitions. But I agree that sometimes it involves
some annoying boilerplate code...
Regards,
Ondrej Kupka
On Apr 22, 2014, at 4:38 PM, Garrett D'Amore wrote:
> 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:
