[nanomsg] Re: macat (mangos nanocat drop-in)

  • From: Ondrej Kupka <ondra.cap@xxxxxxxxx>
  • To: Garrett D'Amore <garrett@xxxxxxxxxx>
  • Date: Wed, 23 Apr 2014 07:30:11 +0200

Hi,

On Apr 23, 2014, at 7:25 AM, Garrett D'Amore wrote:

> So the first stage of refactoring is done.
> 
> This stage is the *protocols*, which all live now in separate packages.  And 
> the strings for protocol names are completely gone.  There was no value in 
> them (as others have pointed out). 
> 

Nice1

> To get a protocol just do:
> 
> import ( “bitbucket.org/gdamore/mangos/protocols/req”)  // replace “req” with 
> which protocol you want
> 
> s, err := req.NewSocket()  // or pub.NewSocket(), etc...
> 
> Then do operations on the socket.  Its that easy.  The string based registry 
> of protocol names, and factories are *gone*.
> 

Yeah, this looks pretty nice. In any case wow, you are fast to act :-)

Ondrej

> I can make “predefined” raw versions like “xreq” and company if folks prefer 
> that to SetOption(OptionRaw, …)
> 
> This proves that the protocols are nice and modular, and we can add new 
> patterns/protocols very easily.  Yay!
> 
> The transports are next. 
> 
> Here’s what the start of macat looks like now:
> 
> package main
> 
> import (
>       "bufio"
>       "encoding/binary"
>       "errors"
>       "fmt"
>       "io/ioutil"
>       "os"
>       "strconv"
>       "strings"
>       "time"
> )
> 
> import (
>       "bitbucket.org/gdamore/mangos"
>       "bitbucket.org/gdamore/mangos/protocol/bus"
>       "bitbucket.org/gdamore/mangos/protocol/pair"
>       "bitbucket.org/gdamore/mangos/protocol/pub"
>       "bitbucket.org/gdamore/mangos/protocol/pull"
>       "bitbucket.org/gdamore/mangos/protocol/push"
>       "bitbucket.org/gdamore/mangos/protocol/rep"
>       "bitbucket.org/gdamore/mangos/protocol/req"
>       "bitbucket.org/gdamore/mangos/protocol/respondent"
>       "bitbucket.org/gdamore/mangos/protocol/star"
>       "bitbucket.org/gdamore/mangos/protocol/sub"
>       "bitbucket.org/gdamore/mangos/protocol/surveyor"
>       "github.com/droundy/goopt"
> )
> 
> The other transport refactoring will add a couple more imports.  But I’m 
> thinking for the transport layer, having the “all” special package would be 
> more useful.  (I agree that there is little value in doing this for 
> protocols, since the app should *really* know what protocol(s) it wants to 
> support.)
> 
> I’ve also moved the test code (most of it any way) into a separate test/ 
> package.  This was the only way I could keep things sane without having to 
> document a bunch of test framework related stuff.
> 
> -- 
> Garrett D'Amore
> Sent with Airmail
> 
> On April 22, 2014 at 1:40:31 PM, Ondrej Kupka (ondra.cap@xxxxxxxxx) wrote:
> 
>> Hi,
>> 
>> On Apr 22, 2014, at 10:35 AM, Garrett D'Amore wrote:
>> 
>>> I’ve implemented “macat” (I did say I suck at names right?) which is a drop 
>>> in replacement for nanocat.  Its really handy for testing, since you can 
>>> have nanocat on one side, and macat on the other.  (There are some things I 
>>> don’t like about nanocat and would like to change, but I thought interop to 
>>> be more useful for now.  Specifically, for some patterns, having a maximum 
>>> receive count would be a nice feature — e.g. receive only “n” packets, most 
>>> often going to be just “1” for a one-shot.
>>> 
>>> https://bitbucket.org/gdamore/mangos/src/e70c9eb062957c9908305b95cba12e5d9056ca50/macat/macat.go?at=master
>>> 
>>> This utility does require another 3rd party library for option parsing.  
>>> (Go’s “flag” package is … lame.  Specifically, I need the ability to have 
>>> repeat options, e.g. multiple instances of “-v” or “—bind” to bind to 
>>> multiple addresses at once.)
>>> 
>> 
>> You can do that using "flag". See Value interface. You can simply wrap a 
>> list or something in this and implement the Set method that would append to 
>> an internal list or so…
>> 
>> Regards,
>> Ondrej
>> 
>>> Anyway, enjoy!
>>> 
>>> -- 
>>> Garrett D'Amore
>>> Sent with Airmail
>> 

Other related posts: