[nanomsg] Re: more updates

  • From: Garrett D'Amore <garrett@xxxxxxxxxx>
  • To: nanomsg@xxxxxxxxxxxxx, Ondrej Kupka <ondra.cap@xxxxxxxxx>
  • Date: Tue, 22 Apr 2014 09:14:11 -0700

On April 22, 2014 at 8:49:16 AM, Ondrej Kupka (ondra.cap@xxxxxxxxx) wrote:

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...


Yep. I’m thinking I should revisit this.

I have some ideas how to minimize application pain here.  A special package 
called “mangos/transports/all” could be imported, and could have a “Register()” 
function.

To be honest, one thing that is really unfortunate is that I have to explicitly 
access something from the package — so that means that application code cannot 
just “import” the “tcp” package but would need to do something like

import (
        "mangos/tcp"
)
...
tcp.RegisterTransport()  // or mangos.RegisterTransport(tcp.Transport())



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: