Path parsing, validating, and normalizing.

[Stebalien]

We currently validate paths after the fact using an IsValid method. Unfortunately, this means:

1. To be correct, we may need to validate repeatedly (not free).
2. We don't really get a chance to normalize the path.
3. Most of the Path methods don't make much sense unless the path has been validated.

So, I'm thinking we may want to change the path interface to something like:

// Path is the path type passed in by the user. It's unchecked and may be relative to some context.
type Path interface {
  // RelativeTo converts the path to an absolute path. If already absolute, this
  // method just normalizes.
  func RelativeTo(p AbsolutePath) (AbsolutePath, error)

  // RawString returns the path as specified by the user. This is never normalized,
  // made absolute, etc.
  // TODO: Do we need this?
  func RawString() string

  // String returns the string representation of the path.
  func String() string
}

// AbsolutePath is an absolute path to a file.
type AbsolutePath interface {
  Path

  // Segments returns the segments of this normalized path.
  Segments() []string

  // Namespace returns the _namespace_ of this absolute path.
  Namespace() string

  // Having second thoughts on whether `Mutable` belongs here...
}

type ResolvedPath interface {
  AbsolutePath
  // ...
}

Thoughts @magik6k?

[magik6k]

I like this.

func RawString() string

I can't think of a good use case for this, might be easier to add it to interfaces when it turns out it would be useful.

Mutable in AbsolutePath

IMO it makes sense for it to be there

It may also make sense to think about integrating paths with #30 and the concept of 'path parsers' / 'mounts' as that could provide a way to finally merge mfs with other paths across the codebase.

[Stebalien]

I can't think of a good use case for this, might be easier to add it to interfaces when it turns out it would be useful.

SGTM. I'm just thinking about errors/feedback: "hey user, we failed to open RawPath() because XYZ". But we're getting ahead of ourselves.

IMO it makes sense for it to be there

My concern is how we'll get this information without hard-coding it. We don't have access to an IPFS node when we construct an IPFS path and I want to be able to support new namespaces through plugins. Although maybe that's not an issue, maybe we should change RelativeTo(path) to something that uses the CoreAPI?

[djdv]

This may be a tangent, but...

Is something like AbsolutePath.Metadata(), more reasonable to have than Mutable()?
Similar to os.FileInfo and the Is* methods.

I feel like Mutable() is useful information, however it feels like it doesn't belong directly on a path.

Edit: ResolvedPath, makes more sense for that I suppose.

[Stebalien]

Paths reference things but don't necessarily mean you have the thing. I'd rather have an explicit coreapi.UnixFS().Stat(path Path) (Metadata, error) method.

[hacdias]

This repository is no longer maintained and has been copied over to Boxo. We are now in the process of reviewing issues and PRs and moving the ones that are still relevant. This issue has been merged with a few other issues, and moved to ipfs/boxo#198.