x/time: create new subrepo for x/time/rate, other code

[Sajmani]

I would like to open-source a package rate that we developed at Google. It provides a rate limiter that supports Context for cancelation and deadlines: a caller can block until either the rate limiter allows the call to proceed or the Context is canceled. It includes an optimization to skip the wait if it would exceed the Context's Deadline. This package is widely used inside Google Go code.

There is no obvious home for this package in any of the golang repositories, so I propose we add a new subrepo, golang.org/x/time, that will contain the rate package as golang.org/x/time/rate. To justify the creation of a new subrepo, it would be useful to identify additional packages that belong here.

[adg]

The "net" repo seems the obvious place for this, to me.

But my opinion aside, issue #12914 is a request for a monotonic clock
source. That seems like a candidate for inclusion for a potential "time"
repository.

On 23 October 2015 at 03:32, Sameer Ajmani notifications@github.com wrote:

I would like to open-source a package rate that we developed at Google.
It provides a rate limiter that supports (Context)[
https://godoc.org/golang.org/x/net/context] for cancelation and
deadlines: a caller can block until either the rate limiter allows the call
to proceed or the Context is canceled. It includes an optimization to skip
the wait if it would exceed the Context's Deadline. This package is widely
used inside Google Go code.

There is no obvious home for this package in any of the golang
repositories, so I propose we add a new subrepo, golang.org/x/time, that
will contain the rate package as golang.org/x/time/rate. To justify the
creation of a new subrepo, it would be useful to identify additional
packages that belong here.

—
Reply to this email directly or view it on GitHub
#13022.

[rsc]

There's nothing about networking in the package Sameer is talking about. It's important that net not become a dumping ground for "anything a server might want".

I think x/time is reasonable. One might envision calendar code going there too.

Who knows? Maybe even monotonic time support, although I am less convinced of that.

Anyway, an x/time repo seems reasonable.

/cc @robpike

[bradfitz]

Yes, my argument to Sameer was that "tools" became a dumping ground and now "net" is becoming a dumping ground. We also have a few things pending perfect for an "x/sync" subrepo if there were one.

Rather than thinking that a subrepo has a high cost, we should really think of a subrepo as a subdirectory of "x" where you can think of "x" as the same as, say, "google3".

[adg]

I agree with @bradfitz we should be creating more repositories.

I'm not familiar with the rate package; it sounded intrinsically
network-related from its description.

On 24 October 2015 at 16:32, Brad Fitzpatrick notifications@github.com
wrote:

Yes, my argument to Sameer was that "tools" became a dumping ground and
now "net" is becoming a dumping ground. We also have a few things pending
perfect for an "x/sync" subrepo if there were one.

Rather than thinking that a subrepo has a high cost, we should really
think of a subrepo as a subdirectory of "x" where you can think of "x" as
the same as, say, "google3".

—
Reply to this email directly or view it on GitHub
#13022 (comment).

[rsc]

LGTM. Leaving for adg@ to create the subrepo.

[Sajmani]

Thank you!

On Tue, Nov 3, 2015 at 1:58 AM, Andrew Gerrand notifications@github.com
wrote:

Closed #13022 #13022 via
golang/build@4154d4f
golang/build@4154d4f
.

—
Reply to this email directly or view it on GitHub
#13022 (comment).