Review abio, consider migrating

[ricardojmendez]

@yogthos suggests reviewing abio and migrating the file system functions to it. We may even want to just deprecate macchiato-fs and simply use abio directly.

[mfikes]

@ricardojmendez Let me know if you have any questions about Abio. The abstractions directly mimic those in Clojure (and Planck implements a variant of them). The implementation in the Abio node binding is currently not much more than a crude POC, and could certainly use some high-quality implementation. As it stands now, Abio is still very early days and in a place where it would be easy to drastically change anything in it.

[yogthos]

I keep meaning to find some time to dig into it. From a brief look I had, it might be good to start by porting the path logic from macchiato-fs. Currently, abio assumes / as the separator as opposed to using system specific separator. It looks like the path namespaces from macchiato-fs could probably be moved over more or less as is.

[mfikes]

@yogthos By the way, feel free to commit directly into Abio.

My philosophical meta-view:

• I suspect developers don't want to code to implementation-specific APIs. (There's the developer cost of learning a new API, and, if the client code depends on implementation-specifics, it is locked-in and less reusable.)
• I also suspect that Clojure and ClojureScript developers would prefer Clojure-idiomatic APIs over using JavaScript interop to work with, say Node.js APIs (or Java APIs if in Nashorn).

With Planck, I've tried my best to not invent any new API where examples exist in Clojure, but still, code still needs to import planck.core, planck.io, etc. and, at best, client code can attempt to avoid locking into Planck by using aliases, but that only goes so far. I suspect the same is true for Macchiato and Lumo, or other runtimes that might appear in the future.

Since ClojureScript itself doesn't provide abstractions for I/O, shell, etc., it seems inevitable that various ClojureScript runtimes / systems will grow their own in order to fill this deficiency.

This could exacerbate things for a developer who wants to, for example, write a portable library that requires I/O facilities. So, one potential solution to the above problems is to add one more layer of indirection, and have code depend on it instead. Abio could be that layer of indirection.

In my opinion, Abio has a much better chance of succeeding at that if it is not "owned" by a single ClojureScript runtime, but instead has shared ownership. Of course, this could lead to disagreements on the best way to address specifics, but I think the few cooks in the kitchen have a lot of respect for each other and are fairly open to ideas.

So, in short, I wanted Abio to not have a feeling of being owned by me, but with committers / owners by a few people in the community. The stuff I put into Abio currently is just a shot in the dark and I don't mind if it is heavily revised.

Also, there should be no feeling of guilt or a feeling of obligation to contribute to Abio. I'm just thinking of it as an experiment that might succeed. If it somehow gains traction within the community that would be cool.

So, in short, feel free to commit, without any need to coordinate or ask permission of me. :)