Andy Wingo <wi...@pobox.com> writes: > Hello all, > > Now that GNU is in the Google SoC, I'd like to propose again a CPAN for > Guile. (It does needs a proper name, but that name doesn't have to > correspond to the name of the command-line utility; see my other mail > about "guido".) > > The proposal would be to start from dorodango, and to use stowfs > locally. We keep (largely) the dorodango network interfaces, but the > implementation exists in a Guile-specific project, with a non-dorodango > name (so as not to conflict with Andreas's more portable project). > Well, I believe Dorodango is quite modular, and large parts could be re-used as-is. Obviously, I'd like to avoid a "real" fork of the codebase -- ideally code should be able to flow easily between Dorodango and its Guile-specific cousin in both directions. I am also open to reconsider design decisions, should some of them not make sense for Guile.
> Locally it uses something like stowfs and $XDG_DATA_DIRS, as noted in > the previous SoC thread. > Support for the XDG Base Directory Specification would indeed be welcome in Dorodango. Also, I am actually quite fond of how GNU Stow works; adding support for that as an additional mode of operation would be nice mini-project. > The project can be developed outside of Guile initially, just > integrating by defining "guido" commands. If everything works it can be > integrated within Guile itself. > One thing that speaks against directly reusing the dorodango codebase (and later moving parts of it into Guile core) is that it comes with some dependencies (from Dorodango's own package metadata): (srfi) ; Not relevant on Guile, it provides the required SRFIs in core (wak-foof-loop) ; Used all over the place (wak-fmt) ; Ditto (wak-irregex) ; Used in a few places; SRE syntax is exposed to the ; user, however (wak-parscheme) ; Used in only one place (minor UI code) (spells) ; That one's really prevasive: pathnames, filesystem, ; logging, ... (industria) ; Only used for handling ZIP, which is quite slow on ; Guile anyway. (ocelotl) ; Weight-balanced trees, HTTP client, URIs. > Andreas, what do you think about this? If you are happy with this I > would be most pleased to have you as a co-mentor. > I'd certainly be willing to answer all kinds of questions on the Dorodango codebase and give advice as good as I can, regardless of what direction the project takes. I have a few ideas that would help bringing the codebase of Dorodango "closer to Guile": - Work on an SRE frontend to Guile's regexp engine. I believe there might be some code out there doing that already (Guile-SCSH?). - Introduce a Stow-like mode of operation. This should be possible without abandoning the current ZIP support, and would allow for: - Using non-random-access archive files (e.g. tar.xz). - Using external programs to (completely) unpack a bundle, eliminating the current performance issue introduced by Guile's relatively slow number-crunching. - Eliminate the (hard) dependency on Industria. So what remains as (quite) hard dependencies would be: foof-loop, fmt, and spells; the others should not be too hard to eliminate in some way or the other. WDYT? Regards, Rotty -- Andreas Rottmann -- <http://rotty.yi.org/>