doc.go 3.26 KB
Newer Older
1
// go-ld-prime is a series of go interfaces for manipulating LD data.
2
//
tavit ohanian's avatar
tavit ohanian committed
3
// See https://gitlab.dms3.io/ld/specs for more information about the basics
4
// of "What is LD?".
5
//
tavit ohanian's avatar
tavit ohanian committed
6 7
// See https://gitlab.dms3.io/ld/go-ld-prime/tree/master/doc/README.md
// for more documentation about go-ld-prime's architecture and usage.
8 9 10 11
//
// Here in the godoc, the first couple of types to look at should be:
//
//   - Node
Eric Myhre's avatar
Eric Myhre committed
12 13
//   - NodeBuilder and NodeAssembler
//   - NodePrototype.
14 15 16
//
// These types provide a generic description of the data model.
//
17
// A Node is a piece of LD data which can be inspected.
Eric Myhre's avatar
Eric Myhre committed
18 19 20 21 22 23 24 25 26 27 28
// A NodeAssembler is used to create Nodes.
// (A NodeBuilder is just like a NodeAssembler, but allocates memory
// (whereas a NodeAssembler just fills up memory; using these carefully
// allows construction of very efficient code.)
//
// Different NodePrototypes can be used to describe Nodes which follow certain logical rules
// (e.g., we use these as part of implementing Schemas),
// and can also be used so that programs can use different memory layouts for different data
// (which can be useful for constructing efficient programs when data has known shape for
// which we can use specific or compacted memory layouts).
//
29 30 31 32
// If working with linked data (data which is split into multiple
// trees of Nodes, loaded separately, and connected by some kind of
// "link" reference), the next types you should look at are:
//
Eric Myhre's avatar
Eric Myhre committed
33 34 35 36 37 38 39 40 41 42 43 44
//   - LinkSystem
//   - ... and its fields.
//
// The most typical use of LinkSystem is to use the linking/cid package
// to get a LinkSystem that works with CIDs:
//
//   lsys := cidlink.DefaultLinkSystem()
//
// ... and then assign the StorageWriteOpener and StorageReadOpener fields
// in order to control where data is stored to and read from.
// Methods on the LinkSystem then provide the functions typically used
// to get data in and out of Nodes so you can work with it.
45
//
Eric Myhre's avatar
Eric Myhre committed
46 47 48
// This root package only provides the essential interfaces,
// as well as a Path implementation, and a variety of error types.
// Most actual functionality is found in subpackages.
49 50 51
//
// Particularly interesting subpackages include:
//
52 53 54 55
//   - node/* -- various Node + NodeBuilder implementations
//   - node/basic -- the first Node implementation you should try
//   - codec/* -- functions for serializing and deserializing Nodes
//   - linking/* -- various Link + LinkBuilder implementations
56 57
//   - traversal -- functions for walking Node graphs (including
//        automatic link loading) and visiting
58 59
//   - must -- helpful functions for streamlining error handling
//   - fluent -- alternative Node interfaces that flip errors to panics
60
//   - schema -- interfaces for working with LD Schemas and Nodes
61 62
//        which use Schema types and constraints
//
Eric Myhre's avatar
Eric Myhre committed
63
// Note that since interfaces in this package are the core of the library,
64 65 66 67 68 69 70
// choices made here maximize correctness and performance -- these choices
// are *not* always the choices that would maximize ergonomics.
// (Ergonomics can come on top; performance generally can't.)
// You can check out the 'must' or 'fluent' packages for more ergonomics;
// 'traversal' provides some ergnomics features for certain uses;
// any use of schemas with codegen tooling will provide more ergnomic options;
// or you can make your own function decorators that do what *you* need.
71
//
tavit ohanian's avatar
tavit ohanian committed
72
package ld