Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make a multicodec.Registry type available. #172

Merged
merged 1 commit into from
May 25, 2021

Commits on May 24, 2021

  1. Make a multicodec.Registry type available.

    The hope is that this might be helpful if you want to build a
    multicodec registry other than the global one, but are still buying
    into the idea of the registry being keyed by indicator numbers.
    
    (I'm... not actually sure how useful this is, because I'd think if
    you're building something other than the default, there's also a good
    chance you'd want *more* features than a primitive numerical mapping,
    which are probably going to be related to whatever your application
    logic in the area is, and therefore not possible for this library
    to usefully anticipate.  But, I dunno.  I'm doing this because
    people are proposing attaching more features to the global, and
    I'm not comfortable with it, and I'm hoping this will provide a
    pressure release valve.)
    
    The current interfaces are functionally unchanged.
    
    The multicodec.Registry type can now be used when constructing
    a cidlink.LinkSystem.  (This saves you from having to write the
    glue functions to unbox cidlink and then do the LookupEncoder
    and LookupDecode calls.)
    
    For where this relates to LinkSystem, I considered a mechanism like:
    `func (r *Registry) InstallOn(lsys *ipld.LinkSystem)` ...
    and probably would've found that a bit cleaner.
    However, it doesn't jive with the way we've isolated the CID types
    into a package with a LinkSystem just for them (sigh; that really is
    the gift of complexity that just keeps giving); you can see how the
    EncoderChooser and DecoderChooser funcs need a tiny bit of type
    assertions in order to figure out how to extract the multicodec
    indicator from the Link/LinkPrototype types?  That bit is a bit
    that we still want to keep cordoned off the rest of the import tree.
    
    DefaultRegistry is also now an exported variable, in addition to the
    functions which already worked with the global data.
    I probably would've preferred to keep the DefaultRegistry variable
    unexported, because I can't imagine any good coming of touching it,
    but the relationship to LinkSystem detailed in the above paragraph
    requires some access to it.
    warpfork committed May 24, 2021
    Configuration menu
    Copy the full SHA
    575054d View commit details
    Browse the repository at this point in the history