rveen / ogdl Goto Github PK

The path parser uses the same byte parser used for OGDL text streams, but OGDL paths should be allowed to be UTF-8 strings. A new parser is needed, or an adaptation of the current one (ReadChar and UnreadChar functions are needed, and those require multibyte temporal storage).

https://www.reddit.com/r/tree_notations/comments/mhvlae/rveenogdl_ordered_graph_data_language_ogdl_is_a/

I wish I had an OGDL library that looked like everything else under encoding/*.

Yes, it'll lose information, and can't round-trip all OGDL data. But it's way more convenient to use than needing to run "queries" on a thing on every access, or writing a function that runs all those queries and returns a struct with the results..

Think of it as ogdl.Graph being the moral equivalent of decoding JSON to interface{}. Used when you know you need to round-trip, but otherwise painful.

It could use struct tags in a way vary similar to encoding/xml, and allow the user to put ogdl paths in them. Something like

network
  eth0
    ip   192.168.0.10
    mask 255.255.255.0
    gw   192.168.0.1

hostname crispin
nameserver 8.8.8.8
nameserver 8.8.4.4

type Config struct {
    Hostname string
    // decoding to a map type knows that the subgraph should be >=2
    // levels deep, first level becomes the keys
    Network map[string]*Interface
    // decoding to a slice value appends every matching subgraph
    Nameserver []net.IP
}

type Interface struct {
    IP      net.IP `ogdl:"ip"`
    Netmask net.IP `ogdl:"mask"`
    Gateway net.IP `ogdl:"gw"`
}

And naturally each field would use encoding/text to actually parse the string. And if the value isn't a string but a subgraph, you could see if the field has a UnmarshalOGDL / MarshalOGDL method, just like JSON; the input to such unmarshal would be a Graph, not []byte.

Even more ideally, this would tie into a streaming parser and avoid holding the graph in memory all at once. And the above UnmarshalOGDL could tie into EventHandler or Parser somehow, too.

I'm quite excited about the potential that OGDL has. It might be able to become an elegant but complete data representation of all Go data types. (XML is ugly but JSON lacks enough ability, YAML is also too heavy).

The only format that is able to represent complete Go types is encoding/gob, but it is a binary format. Go just lacks a pretty text format to do it.

1. OGDL can now support reference cycle, right? So pointer or interface is not a problem.
2. It just need a standard way to represent map, array and struct, as extension to current OGDL standard.
3. Then it can implements methods like Marshal, marshalIndent and Unmarshal as in encoding/json.

If you are interested in my proposal, I'd like to contribute to its implementation.