Go wrapper

[rdallman]

In gitlab by @treeder on May 11, 2017, 17:11

• both default and hot function support

[rdallman]

In gitlab by @treeder on May 11, 2017, 17:24

changed milestone to %4

[rdallman]

In gitlab by @treeder on May 15, 2017, 15:53

changed milestone to %5

[rdallman]

In gitlab by @treeder on May 18, 2017, 13:08

changed milestone to %1

[rdallman]

In gitlab by @hibooboo2 on May 19, 2017, 14:54

assigned to @hibooboo2

[rdallman]

In gitlab by @hibooboo2 on May 19, 2017, 15:02

Going to tackle this want to clarify what the lib should add / do as a general case.
This what I think it should handle looking for feedback to see if I am track before I start.

• Normal function

  • Read from stdin until it is done being read.
  • Allow you to read from stdin to json assuming you are recieving json..
  • Same but for yaml toml etc....
  • Read As if it is just text
  • Get headers using env vars easily...

• Hot functions

  • Read from stdin on loop using the http format defined in functions.
  • Put that info into a usable format that is passed into a function call that runs on loop and on return puts the response to stdout.
  • Easily handle methods and status codes?

[rdallman]

In gitlab by @treeder on May 21, 2017, 15:28

Main thing here is to define what the interface for users will be. See Lambda for example in Java (http://docs.aws.amazon.com/toolkit-for-eclipse/v1/user-guide/lambda-tutorial.html) and node (http://docs.aws.amazon.com/lambda/latest/dg/nodejs-prog-model-handler.html).

[rdallman]

In gitlab by @treeder on May 22, 2017, 11:23

How about something along the lines of:

type Handler interface {
      Handle(ctx context.Context, input func.Input, func.Output)
}

type Input interface {
     Read(p []byte) (n int, err error) // implements io.Reader
     Header(name string) string // should we call them headers?
}

type Output interface {
     Write(p []byte) (n int, err error) // implements io.Writer
     // TODO: some way to set content-type, etc
}

[rdallman]

In gitlab by @rdallman on May 22, 2017, 13:23

@treeder looks nice. still need to define the actual code the user puts in i.e. main so what you're saying is:

import (
  "odx/gofn"
  "strings"
  "io"
)

func main() {
   var m myThing
   gofn.Handle(m.Handle)
   // maybe gofn.Handle(gofn.HandleFunc(handler)) ?
}

type myThing struct{}

// implements fngo.Handler
func (m *myThing) Handle(ctx context.Context, in input fngo.Input, out fngo.Output) {
  io.Copy(out, strings.NewReader("yodawg"))
}

as for other langs, it would be nice if they were all kind of consistent and this is a pretty go-specific implementation (due to use of interfaces). if every language has closures then maybe we can pull off something with some uniformity like:

func main() {
  gofn.Handle(yodawg)
}

func yodawg(ctx fngo.Context) {
  // yes I realize your example works in this case, but note the function header
  io.Copy(ctx.Output, ctx.Input)
}

or:

func main() {
  gofn.Handle(yodawg)
}

func yodawg() {
  io.Copy(os.Stdout, os.Stdin)
}

i.e. everything is either shoved into the fngo.Context or into the "normal" function path using stdin and stdout and then gofn.Handle would basically be:

func Handle(f func()) {
   for {
      // readIn will read a standard or normal function input from stdin and output body and vars (you get the idea)
      in, vars, isHot := readIn(os.Stdin)
      io.Copy(os.Stdin, in)
      setEnvVars(vars)
      f()
      if !isHot {
        break
      }
   }
}

eh? my thinking is mostly like in ruby / python / java / etc etc we can make a similar "fn.Context" which has a "familiar" fn.Context.Input and fn.Context.Output and fn.Context.Vars or we just shove things back into how they are in a "not hot" function. just a brain dump from me, not too opinionated either way. thoughts ?

[rdallman]

In gitlab by @hibooboo2 on May 22, 2017, 13:29

IMO the wrappers do not need to be uniform across languages as each language has different patterns and idioms and will need a custom wrapper... So making them similar would be good but Do not think they need to all be the same... Up to you guys though... @treeder What do you think?

[rdallman]

In gitlab by @treeder on May 22, 2017, 14:06

I tend to agree with you you @hibooboo2 , should be what a user would expect based on the language.

@rdallman I was thinking there wouldn't be a main, you just define the function. Then on fn run it would wrap it and build it. Similar to other languages on Lambda.

[rdallman]

In gitlab by @rdallman on May 22, 2017, 14:14

for go specifically the code won't build (locally, not using fn wrapper stuff) without a main() in package main and if they don't use package main then we would have to create a package main and import their package and then call their handler or change their package to package main on the fly so, seems kind of crufty, and not too hard to make them write main() and then it all falls out pretty intuitively. for javascript, lambda specifically, they can just eval shit, so it's a little different (just write your function and then unicorns). i can imagine other languages being similarly weird to Go but as you say, maybe some langs we don't have to, but we don't have the benefit of throwing functions at vms like lambda does since we're using docker so we at least have to generate or force them to write code that actually executes the code they want -- i guess it's pretty obvious i lean towards the former.

[rdallman]

In gitlab by @treeder on May 23, 2017, 09:53

We might want both things now that I think about it. I nice library that can be used if you want more control. But the default, simple way would just be a handler that gets wrapped with a main() and all the goodies.

Fission does it an interesting way using plugins: https://github.com/fission/fission/tree/master/examples/go

[rdallman]

In gitlab by @rdallman on May 23, 2017, 10:50

fission appears to use package main in their example, I guess I don't really see the benefit of being able to omit 3 LOC. woo fuckin hoo

[rdallman]

In gitlab by @treeder on May 30, 2017, 14:55

added ~6 label

[rdallman]

In gitlab by @carimura on May 31, 2017, 08:36

removed ~6 label

[rdallman]

In gitlab by @treeder on Jun 13, 2017, 10:12

changed milestone to %4

[rdallman]

closing, see http://github.com/fnproject/fdk-go