blob: remove global registry for Open

[zombiezen]

blob.Open currently operates from a global, mutable registry (populated with blob.Register). Go Cloud emphatically tries to avoid the pattern of having a global registry due to the confusion that can come in the face of conflicting keys and the difficulty of reasoning about side effects, especially when incorporating into a large application or when multiple incompatible versions are present. Avoiding global mutable state in favor of explicit construction is preferred.

Proposed Change

The blob package should grow a new type (called Opener below, but exact name TBD) that manages the mapping to different implementations. A reasonable default package can exist in the Go Cloud repository that imports GCS, S3, and Azure.

package blob

// An Opener returns buckets that map to pseudo-URLs.
type Opener struct {
  // ...
}

// NewOpener returns a new Opener that uses the given mapping of protocol schemes.
func NewOpener(schemes map[string]FromURLFunc) *Opener

// Open returns a bucket for the given URL based on its mapping.
func (o *Opener) Open(ctx context.Context, urlstr string) (*Bucket, error) {
}

and elsewhere:

package cloudbuckets

import (
  ".../azureblob"
  ".../gcsblob"
  ".../s3blob"
)

// Opener returns a *blob.Opener that maps URLs to common cloud providers.
func Opener() *blob.Opener {
  // ...
}

While this adds a bit more setup code, it:

• Allows different *blob.Openers to be present in different parts of the application
• Makes the connection between the Open call and the bucket much more explicit
• Permits decoration or alteration of the FromURLFuncs being sent to the opener

/cc @vangent @shantuo

[vangent]

Importantly: can you add code snippets showing how a user application would use this? Assume they want to pick and choose which providers they want to support (although choosing the "default" ones should be easier).

[jba]

Is it worth currying this? We could just have

blob.OpenURL(urlstr string, schemes map[string]FromURLFunc) (*Bucket, error)

[vangent]

On #981 (comment), @clausti suggested that maybe the scheme(s) that a provider registers for should be exposed as public constants for the package.

[zombiezen]

One additional consideration that occurred to me while hacking on this (and this might be a separate issue): do we want to support being able to open readers and writers by URL? It seems like a natural extension.

EDIT: This is a separate issue. Opened #1101 to track.

[zombiezen]

Obsoleted by design decisions in #1174.