Closed jbenet closed 10 years ago
All this could get out of hand with lots and lots of conversion implementations. Ideally you'd have one conversion between any type pair and be done. But it is reasonable to assume that implementations will not be perfect and thus will need to allow other implementations to be published and used.
Maybe this is where namespacing can be useful. rather than people publishing:
transformer-foo-to-bar
transformer-foo-to-bar-better
transformer-foo-to-bar-2
transformer-foo-to-bar-fast
and confusing users with unclear names (is foo-to-bar-fast
either "a 2nd implementation of foo -> bar
" or the first implementation of "foo -> bar-fast
" ??). We could setup a culture of publishing:
transformer.foo-to-bar
transformer.foo-to-bar.jbenet
transformer.foo-to-bar.fast
transformer.foo-to-bar.using-c-lib
This way, it is clear what the conversion is. SOOO maybe the npm naming really should be:
transformer.<id>[.<optional namespace/tag>]
And if a clearly better conversion rises, we can repurpose the un-namespaced package. transformer.<id>
would module.exports = require('transformer.<id>.other-impl')
Seems to have settled on this approach. can revisit later if needs to change.
@maxogden pointed out that it's not very flexible to community contribution to use deterministic naming as the only way to use a conversion. This is particularly bad when >1 implementations of the same conversion exists. It should be possible to:
a) add new, different implementations of conversions b) let others use these conversions c) not disrupt the current users of existing conversions
So, the naming convention (
transformer-<type-name>
andtransformer-<type-name>-to-<type-name>
) is good, but should not be the only way to do it.This is complicated further by the desired api:
or in the cli:
Say converting from
my-format-a
tosome-format-z
requires composing multiple intermediate conversions (a -> b -> ... -> z
). If every conversioni -> j
can have multiple implementations, selecting the right one (for all) can become difficult.For now, it can be fine to have to construct the composition explicitly:
But eventually we'd like to be able to automatically suggest + select the conversions. At some point, something like this will be possible:
(The
ip-address-to-buffer2
, an alternative implementation of the conversion.) And then we could find good ways of selecting conversion "routes".