Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Possible easier to use top-level API #37

Open
bassosimone opened this issue Feb 11, 2020 · 0 comments
Open

Possible easier to use top-level API #37

bassosimone opened this issue Feb 11, 2020 · 0 comments
Labels
bug Something isn't working

Comments

@bassosimone
Copy link
Contributor

bassosimone commented Feb 11, 2020

It seems the current API based on channels is not very comfortable to use. A better design would probably be to expose a blocking API with a callback, for example:

func (c *Client) Run(ctx context.Context, fn func(m *spec.Measurement)) (summary Summary, err error) {
  var ch chan spec.Measurement
  ch, err = c.StartDownload(ctx)
  if err != nil {
    return
  }
  for m := range ch {
    // TODO: fill the summary
    fn(m)
  }
  ch, err = c.StartUpload(ctx)
  if err != nil {
    return
  }
  for m := range ch {
    // TODO: fill the summary
    fn(m)
  }
  return
}

This may or may not be combined with a summary. Note that this API does not cause data races because the callback is called in the same thread context of the blocking Run call.

@bassosimone bassosimone added the bug Something isn't working label Feb 11, 2020
@bassosimone bassosimone changed the title Possible easier high level code pattern Possible easier to use top-level API Feb 11, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants