Internal APIs currently needed for several significant use-cases

First, thanks for the creating this awesome library!

There are a few use-cases which seem to be difficult to implement without access to APIs that are currently designated as “internal”.

Decorated HTTP plugins

The decorator pattern would be a natural choice for those wishing to modify the default http behavior in new ways without completely re-implementing it. However, as far as I can tell, once you replace the default http plugin, there isn’t a good way to delegate to it from the decorator.

Implementing the server-side of pack upload/download

Most of the pieces already exist in isomorphic-git for a client to use the library to implement a git server supporting pushing/pulling changes. I have a prototype which supports git clone over WebRTC which required very little glue code - the main new piece was an ‘side-band-64k’ protocol implementation based on the commented code already present in isomorphic-git.

Unfortunately, this already required access to several internal parts of isomorphic-git (uploadPack, GitPktLine, collect, parseUploadPackRequest, listObjects), without which I would have had to duplicate a great deal more code.

[jcubic]

You don’t need to apologize, the PR are merged pretty fast, so if someone have a feature implemented it’s included with the main repo, and releases are automated. I only need to merge, which I can do even on my phone, which I’m using right now.

If you want to contribute that would be great, you are free to implement the feature as you want we only need to agree on the API, that need to match to the rest of the project.

[dionysiusmarquis]

Git request/response tunneled as stream would be heartwarming. I was just looking for a way to implement decentralized git for libp2p