Imports

[jbenet]

@blambeau: This expands on our discussion.

Finitio needs a way to link different schemas together, allowing importing other local files, or across entirely separate projects. This is a really important software management problem. How well languages solve this often drive adoption and continued use.

Take a look at these three aproaches first, before picking or combining. And, remember that in 2014, you can leverage the web, DNS, and other internet systems to make everyone's life easier.

1. The Package Manager Approach

Define a package spec, and make directories containing finitio code conforming to the package spec be importable modules. Then write a package manager + registry service to host and serve the packages. npm is the most notable example.

Pros:

• Very Flexible
• Well established workflow.
• One public, central registry to publish schemas.
• Can be linked to github/gist easily.

Cons:

• Yet Another Package Manager (perhaps we need a PM library :) ).
• Requires maintaining central registry.

If you think this is the right approach, let's discuss, as datadex could potentially host these too.

2. The Go Approach

Go imports basically work like this:

import (
    "io"                         // <--- from stdlib
    "github.com/jbenet/data"     // <--- from github, uses git
    data2 "github.com/foobar/data" // <--- import as 'data2'
)

Pros:

• Super flexible: use VCS repositories directly.
• One global namespace! And well designed, leveraging the existing global namespace: URLS.
• No central registry needed! Your OSS repo is all you need! This feels magical!

Cons:

• No versioning. Should allow fixing version in the import.
• No central registry backs up imports. If the original repo disappears, you're out of luck.

People are solving these big problems by forking before importing. Given how git works, this is not ideal. Go could just as well do any of:

import (
    "github.com/jbenet/data@abc123"
    data @abc123 "github.com/jbenet/data"
    "github.com/jbenet/data/version/abc123"
)

(This could also be solved github/vendor side, by serving "github.com/username/repo/version/<commit>" as a repo with master pointing to <commit>. I believe Google does something like this internally, with its p4 installation, which is probably why the Go team isn't pushing a solution. But I digress.)

3. The Linked Data Approach

Making Finitio play nice with the already huge linked data world could make it easy to integrate to current workflows. Take a look at JSON-LD and schema.org, as a super light and clean Linked Data approach. Pros:

• Linked Data interop!

Cons:

• Standards are hard.

Should think through whether this belongs in the language, or as a combined approach (use a Package Manager that uses package.jsonld.)

---

My Recommendation

I would recommend a hybrid of the three: use imports like Go's (but with version fixing), and use a package manager to provide (a) backups and (b) linked data interop.

Something like any of these:

Temp = <stdlib.Temperature>
Temp = <datadex.io/jbenet/myproject@abc123#Temp>

import Temp from datadex.io/jbenet/myproject@abc123
import Temperature from datadex.io/jbenet/myproject@abc123 as Temp

import datadex.io/jbenet/myproject@abc123
Temp = myproject.Temperature

The syntax will obviously vary (and excuse if the < > are wrong here), but it's important to get critical functionality right. Note (a) renaming, (b) whole module imports, (c) selective single-type imports, (d) version fixing, (e) global namespace support. Publishing a module/package to the registry would work as in npm, datadex, etc. (with a package.jsonld file).

[blambeau]

@jbenet Thanks for raising this issue and summarizing various approaches.

Finitio has many different use cases so I will certainly favor something that is open & simple enough to cover those. For instance, I'm not sure that a central package manager approach makes much sense in the scenario where people consume RESTful APIs having Finitio metadata/schemas. In the other hand, sharing type definitions à la schema.org probably requires such a package manager. That also avoids the "github is not a CDN" kind of problem.

I think that leveraging the web, DNS, URLs is indeed the way to go. I'll make a proposal ASAP.