I guess you assume that we are actually checking if there are issues open and closing them when the bugs get fixed. That's definitely not true for my repositories and I am not planning to spend time on this.
https://github.com/lionkov/go9p was superseded by https://github.com/lionkov/ninep (I was told that some people dislike packages that start with go). I don't know of any bugs in it, if there are some, I'd be happy to fix them (but not close the issues :) I believe Ron's HarveyOS/ninep is a clone of mine repository. On Sun, Feb 19, 2017 at 10:39 AM, Jason E. Aten <j.e.a...@gmail.com> wrote: > I'd like to play with the 9p protocol (plan9's "everything is a filesystem" > IPC protocol; I guess the updated 9p2000 version is the one everyone > actually uses) ... > > ...but the implementations I can find in Go seem > half-done/incomplete/unmaintained. > > http://9p.cat-v.org/implementations + other searches turned up: > > > 0) https://github.com/9fans/go - Last commit 2 years ago. 2 outstanding > issues, 8 outstanding pull requests. Appears orphaned. > > 1) https://code.google.com/p/go9p/ seems to be superceeded by > https://github.com/lionkov/go9p - 6 open issues including race conditions > that appear quite serious. > > 2) https://github.com/rminnich/go9p/ - last commit in 2015, 3 outstanding > issues, 7 outstanding pull requests > > 3) https://github.com/Harvey-OS/ninep - recent activity as of 11 days ago > (yay), but an open issue indicates ongoing data races and experimentation > with the implementation that indicates it is likely not stable or usable by > 3rd parties. > > 4) https://github.com/docker/go-p9p - six open issues, some of them serious > and indicating that it cannot interoperate with other 9p implementations > > 5) https://github.com/joushou/qp - very little documentation and its build > is failing > > So to my question... > > Does anyone know of, or have a pointer to, a working/solid/correct 9p > (9p2000) client/server library in Go? > > > Perhaps the authors of the above could chime in and clarify if their package > *is* actually in good shape, despite appearances. > > > NB the problematic licensing of any code derived from the original C > implementation means I'll need to locate a non-Lucent license in order to > use a lib. So this rules out a straight port of the C. > > Thanks! > > -J > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
