scope HTTP cookies.
The golang.org/x/net/publicsuffix package contains a 'compiled'
version of the plain text list . That compiled version that is more
efficient at runtime, but not human-readable.
The canonical upstream list gets ad hoc updates roughly once a week in
recent times . We (usually me, sometimes Brad or Volker)
occasionally update the Go package, maybe once every few months . I
hesitate to do so more frequently because even a one line change to
the upstream list pretty much changes the entire generated table (
is a typical diff), and I don't want to bloat the golang.org/x/net git
repo with lots of essentially binary changes. I'm really only hand
waving and guessing here, as I don't really know how git works under
the hood, but for example, the generated table.go file currently
weighs 528K. At , Brad (who's away for some weeks) said that each
publicsuffix commit grows the x/net repo by 0.1MB, which isn't huge,
but it would add up over time.
On the other hand, we've had a number of CLs sent in over the years
because the checked in, generated version becomes stale, and these CLs
have arrived more frequently in recent months. It may be time to
update the generated form more frequently, if not automatically. Any
thoughts or experience out there with automatic code gen and "git
Automatic or not, it might then make sense to move the package to its
own dedicated git repo, instead of filling golang.org/x/net with noisy
churn. If so, any bikeshedding opinions between
golang.org/x/publicsuffix (gerrit + codereview) or
github.com/golang/publicsuffix (vanilla git) or something else?
Any other thoughts, golang-dev?
golang.org/issue/15518 also has some discussion of building the list
at runtime instead of at "go generate" time, if users supply a
public_suffix_list.dat file at runtime, but it is a nice property that
the package is currently usable out of the box with "go get" and
without having to supply a separate list. Also, if you need a process
to update that separate list, you might as well have a process to
update the Go package, modulo the repo size issue, if the Go package
was updated more frequently.
It is also trivial for third parties like chromium or letsencrypt to
fork the package and run "go generate" at whatever cadence they want
to, although all this might lead to is having N replicated problems
instead of 1 centralized problem.
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to email@example.com.
For more options, visit https://groups.google.com/d/optout.