search

mami-project / postsocket

Go implementation of PostSockets over various transports
3 stars 1 forks source link

Is this API meant to compile? I get build errors #1

Open markdingo opened 7 years ago

markdingo commented 7 years ago

go/src/github.com/mami-project/postsocket/api.go:21: undefined: Message go/src/github.com/mami-project/postsocket/api.go:25: undefined: Message go/src/github.com/mami-project/postsocket/api.go:58: undefined: LocalIdentity go/src/github.com/mami-project/postsocket/api.go:59: undefined: RemoteIdentity go/src/github.com/mami-project/postsocket/api.go:66: undefined: RemoteIdentity go/src/github.com/mami-project/postsocket/api.go:70: undefined: LocalIdentity go/src/github.com/mami-project/postsocket/api.go:71: undefined: RemoteIdentity go/src/github.com/mami-project/postsocket/api.go:245: undefined: RemoteIdentity go/src/github.com/mami-project/postsocket/api.go:263: undefined: net in net.IP

mirjak commented 7 years ago

Hey, Mark this is still under development. Happy to take PRs if you are working on this!

markdingo commented 7 years ago

In the next couple of weeks or so I'm hoping to start a POC implementation to stress-test the IETF draft so my first order of business is to a) ensure the API compiles and b) ensure the API matches the current draft.

On the former, it mostly looks like we need to create some interfaces for the missing entities: Message, LocalIdentity, etc. No big deal.

On the latter I'll have to grind thru the spec unless you know first-hand how much the current draft differs from when this repo was last updated.

britram commented 7 years ago

We expect to submit a next revision by the IETF document deadline a week from Monday; this will bring the draft into line with our present thinking (which is outlined in more detail in the FIT paper on Post Sockets)

In general, though, the appendix in the draft is meant more as an example, to illustrate how the abstract API could be made concrete, than it is as a complete interface definition. We do intend to implement Post in Go, though, and the full interface definition should appear as part of that module, which should in turn be referenced from the draft.

markdingo commented 7 years ago

Right. Three thoughts that come to mind are:

  1. There needs to be a cleaner division between the API and the implementation - perhaps adopting a model along the lines of database/sql whereby various transports are providers or drivers. (One could argue that Sink and Source are really just no-op providers.)

  2. I wonder whether a number of the functions should be turned into receiver functions, such as NewAssociation:

func (pc *PolicyContext) NewAssociation(li LocalIdentity, ...)

This is more in line with the go model.

  1. Should Carriers or Messages have a context so that they be cancelled? It seems that all of the go packages that deal with network/async functions are adopting a context approach.
britram commented 7 years ago

On (1): yes, exactly. See the FIT paper on the Carrier/PSI split, which has not yet carried over into this document.

On (2): making "the policy context" (which is actually a stack of policy contexts a la CSS) the receiver for the core functions is not something we'd considered, and I'm not sure why not. It's a pretty good idea.

On (3)... maybe. A core part of the PostSockets contract is that handing a Message to a Carrier with a lifetime is essentially met with a promise to cancel not before that lifetime expires if the Message has not yet been sent. I'm not sure that exposing a context through the API is the best way to meet that contract, but it's certainly the best way to implement it internally. I really don't want to expose that in the appendix of the draft, though, since it's a pretty language-specific mechanism.

The answer to the original question asked by this issue, though, is "no", though it's meant to be related to an interface to a PSI-based implementation that does build. It turns out that's a different repo: https://github.com/mami-project/postsocket. Note that that repo also doesn't build, as I caught an interrupt four months ago and haven't returned from the stack yet, but at least it's meant to. :)