At its core, the PGXN API server is just another mirror. It has an hourly cron
job that rsyncs to the master mirror, updating the mirror. But then it
iterates over the rsync log and transforms some things. Here’s what it does:
At its core, the PGXN API server is just another mirror. It has an hourly cron
job that rsyncs to the master mirror, updating the mirror. But then it
iterates over the rsync log and transforms some things. Here’s what it does:
README file and any files recognized by Text::Markup and
converts them to sanitized HTML with a table of contents. Such files can
then be used to display the README on the distribution page and to
display individual documentation files.META.json generated by PGXN Manager. For example, as of this writing, the
API server’s semver 0.2.1 META.json and the unversioned semver.json
are identical. Effectively, this format has all the metadata from the
META.json as well as a list of all releases of the distribution from the
semver.json. This is useful for displaying all the data on the
distribution page by fetching the data in a single API request.META.json file. For example, if you look
at the semver 0.0.0 META.json, you’ll see that it includes 0.2.1 in its
list of releases, even though 0.2.1 was released after 0.2.0. This allows
semver 0.2.0 page on the main site to have a select list of version to
choose from, including versions released later, with a single API request.semver.json to the API semver.json.theory.json to the
API theory.json and the mirror data types.json to the API
data types.json. This allows the user page and tag pages to include
the abstract in the list of distributions released by the user or associated
with a tag.All of this merging stuff came out of my thinking following the discussion of the PGXN API RFC. The decision to use Lucy instead of PostgreSQL’s full-text search followed rather naturally from this, as I quickly realized that there was no other driving need for a relational database behind the API at all. The only dynamic API is the search API. Everything else is just static files. And given the performance issues of in-database search, as well as the desire to have fewer outside dependencies, made the decision a natural one.
Beyond the syncing, there is a very simple web server providing the HTTP REST interface to the static JSON files and the full-text search. That’s it, really. The API server is really just another mirror on steroids. The nice thing is that it allows an interface, such as WWW::PGXN or the new PGXN client to work with either interface, just failing gracefully when API server APIs are unavailable.
If you want to learn more about the specifics of the REST API, the API documentation has all the details. Really, it’s quite comprehensive!
I actually consider the API to be 1.0-complete at this point, unlike PGXN Manager. The only thing I want to add is JSONP support for static JSON files (right now it’s only for search results) and might tweak a few things here and there, but otherwise I think it’s in pretty good shape.
Longer term, though, it might be worthwhile to add some other features to enhance the value of PGXN overall. Some ideas:
But I think we need to build up some momentum on the foundation that’s in place. Have you submitted your extensions, yet?
]]>So if you’re interested in use the API for various things, please have a look! I’d appreciate any feedback or corrections.
]]>So if you’re interested in use the API for various things, please have a look! I’d appreciate any feedback or corrections.
Speaking of users of the API, Daniele Varrazzo has started writing a PGXN client app in Python. This is so awesome! It makes me happy that people are able to just get going on this. And Daniele did it before I’d written the docs, just from reading the PGXN source code. Nice!
Anyway, getting these docs written was the last barrier I had to releasing
various pieces of PGXN on CPAN and generally being able to get on with my
life. I wanted to write these docs first so that I would have a little more
freedom to change things if something struct me as especially stupid.
Fortunately, as I’ve written the main site as a thin client for the API,
most of the lameness has already been excised. I think the only change I’d
like to make is to change the {char} URI template variable for the
userlist API to {letter}, because only lowercased ASCII letters a-z are
allowed. It’s more accurate.
Another thing I think I’ll change is the file name suffix used for the
distribution download files. Currently it’s .pgz, but after Daniele
complained about it, I asked around and the concensus seems to be to change
it to .zip. I’ll likely do that tomorrow, too. Fortunately it’s pretty easy:
Just edit the configuration file and rename the files on the master mirror. At
least it should be that easy!
There was one other thing in the APIs the felt a bit silly, but I don’t remember what it was, so screw it.
Anyway, feedback on the API docs would be greatly appreciated. And – get hacking!.
]]>READMEs,
extensions metadata, and usersREADME (example)The entire site is backed by the API Server, which is mainly composed of static JSON and HTML files read by the site back end from the local file system. So the site is quite fast. Please browse around, let me know what you think, and please report any bugs you find.
]]>READMEs,
extensions metadata, and usersREADME (example)The entire site is backed by the API Server, which is mainly composed of static JSON and HTML files read by the site back end from the local file system. So the site is quite fast. Please browse around, let me know what you think, and please report any bugs you find.
There are a few more things left to do on my list:
gettext and solicit translations.$nickname@pgxn.org addresses, to forward to personal
addresses; this way we can just publish pgxn.org addresses.If you’d liked to help out with any of these tasks, just let me know. Better yet, grab the source from GitHub and just hack!
Oh, and speaking of the source, I would really appreciate a code review or four. Although I have solicited advice on key questions fro people more knowledgeable than I (thanks Aristotle, Miyagawa, Andreas, Graham), the code is entirely my own. More eyes will be a huge help!
Tomorrow I’ll blog a bit about the architecture for the network. I’m quite happy with it.
]]>/dist/pgTAP/, and that page would use Ajax requests to fetch the data from
the API server and display stuff. I think this will work pretty well except
for one thing: 404s.]]>/dist/pgTAP/, and that page would use Ajax requests to fetch the data from
the API server and display stuff. I think this will work pretty well except
for one thing: 404s.
That is, if you request /dist/nonexistent/, then it will load a page with
the HTTP status code 200 OK, but then, when the Ajax request 404s, it will
show a “Not found” error message. That’s all well and good, but I’m wondering
about the impact of two things:
Since the page itself won’t 404, search engines might index links to nonexistent extensions. Of course, bad links won’t be that common, but of course they do happen and then tend to live forever.
If the search site uses Ajax to fetch the contents of a page via JSON (or, for documentation, as an HTML document it will put into a div), will the full content be properly indexed by search engines?
So these are serious questions, in my mind. Do we loose good search engine indelibility when we load content dynamically?
Of course, I can instead write it so that the back end fetches stuff from the API server (and perhaps directly from the file system) and get ‘round these issues, but then it’s less of a cool example of the use of the API server.
What do you think? Good advice much appreciated!
]]>Well, sort of. First of all, I’ve decided that the “search site” should not be a separate thing. The main site will be the search site. This is following the example of JSAN, as well as feedback from Graham Barr, who created and maintains CPAN Search. Apparently people are often confused that search.cpan.org is separate from www.cpan.org. No point in adding in confusion from the beginning. And besides, now that the PGXN fund-raising is over, I don’t know what else would go on the home page.
]]>Well, sort of. First of all, I’ve decided that the “search site” should not be a separate thing. The main site will be the search site. This is following the example of JSAN, as well as feedback from Graham Barr, who created and maintains CPAN Search. Apparently people are often confused that search.cpan.org is separate from www.cpan.org. No point in adding in confusion from the beginning. And besides, now that the PGXN fund-raising is over, I don’t know what else would go on the home page.
The other thing that’s happened is, just as I was getting my butt in gear on this stuff, a new CPAN search site came to my attention, μετα CPAN. This is an interesting project. What they did instead of creating a monolithic HTML search site is to create a simple API that serves nothing but JSON. It has search and displays metadata for CPAN objects (distributions, maintainers, modules, etc.). The search site, then, is not really a site at all, but a pure JavaScript application. Once you load it, it just uses the API server to get all the data. There are a few tricks server-side to proxy the API server so as to avoid cross-site scripting issues. But otherwise it just works in the browser.
Now I’m not sure I’ll do the same thing, exactly, but there’s a lot of appeal in creating a RESTful API server that’s independent of the search site, and then building the search site to use it. It also has the advantage of being useful for other projects to just use. Want to create a PGXN search widget for your blog? Yeah, there’s an API for that.
Of course, thanks to the “RESTful Directory” design for the mirrors (described here and revised here), any mirror is a lightweight API already. There’s a lot of metadata one can get just from the static JSON files it generates. The design is flexible–but designed with a command-line client in mind. As such, many commands executed in a command-line client would likely requires multiple requests to a mirror. For example:
> install pgtap
This would request /by/extension/pgtap.json from the server. It would then
parse that file and see that the latest stable version of pgTAP is in the
distribution “pgTAP” at version “0.25.0”. So it would then download
/dist/pgTAP-0.25.0.pgz to install.
This is great for a command-line client, but wouldn’t be so great for a search site to be responsive. Ideally, a site should send a single request to get all the data it needs for a particular page.
So here’s what I’m thinking for a PGXN API server: It will offer a superset of the functionality of any other PGXN mirror. That is, all the JSON files in a mirror will be present, but many of them will have more information than they would on other mirrors. And then, of course, there will be other URIs to offer additional API calls.
So what does that look like? Let’s take the pgTAP distribution, which I released on PGXN earlier this week. To find the pgTAP distribution, one requests:
From that, one can see that the latest table release is 0.25.0, and so one can then request
to get all the metadata for that particular release. What I propose, to avoid the two requests, is to include the contents of the second file in the first. That would then have all the data necessary to generate the pgTAP distribution page on the PGXN site.
The API would offer similar supersets of data for the extension , owner , and tag metadata files, to have the data necessary for the design of the corresponding extension, owner and tag layouts of the site.
In addition to adding metadata to the existing mirrored JSON files, there would be other resources available for request from the API server. They would include:
Extension Documentation. Each distribution may include documentation for
included extensions in the doc subdirectory. These will go under the
directory for a specific distribution such as
/dist/pgTAP/pgTAP-0.35.0/doc/pgtap.html. The latest version of each
document would also be available under /by/extension, as in
/by/extension/pgtap.html. This requires that the documentation file have
the same base name as the extension file itself.
Other documentation. I’d like to support arbitrary documentation, such as for included binary executables, HOWTOs, etc. The canonical copies will go under the versioned distribution URL, of course, but I’m not sure about permalinks. That might require an extension of the Meta Spec; I haven’t quite figured that out, yet.
Source code. There will be an interface to browse an unpacked copy of any
distribution as plain text. This will be under /src, as in
/src/pgTAP/pgTAP-0.35.0/.
Of course. This is the big one, really. I think it makes sense to have the
/by URI respond to search requests. Thus, a request for
/by?q=testing
would search everything. If you only want to search a certain category of object, you’d hit the appropriate URI:
/by/dist?q=tap
/by/owner?q=clochard
/by/tag?q=test
/by/extension?q=gis
The nice thing about this is that it retains the existing entity URLs. The directory level determines which entities you get.
So that’s my thinking on the search API. I’m going to start hacking on it in earnest tomorrow, and perhaps next week I can get a very early version out (basically just another mirror to start with).
But what do you think? Seem like a sane approach? Am I missing anything obvious or doing anything clearly stupid? Please let me know in the comments!
]]>I’m pretty happy with how the database API is turning out. See the nifty
database API documentation I whipped up using gendoc and embedded
MultiMarkdown. There are still a few tweaks I need to make. I just checked
in a change to eliminate all the ALIASes I blogged about last week. Turns
out that one can just function-name-qualify the function parameter names.
Who knew? I sure didn’t.
But I do have a question for you, dear readers. Right now, the database requires that extensions have unique version numbers in every distribution. So if, for example, you uploaded the distribution foo 1.2.2 with the extension bar 1.2.2, when you next uploaded foo 1.2.3, bar could not be 1.2.2. I designed this this way by following my own practice of always incrementing the version numbers of all modules included in my CPAN distributions. So all modules have unique version numbers, with never a duplicate.
However, CPAN itself only cares that distributions have unique version numbers. It doesn’t care about the version numbers of included modules. See, for example, HTML::Mason. Note that the various included modules have all sorts of different version numbers, and many have no version numbers at all. So while the core module has a version number (1.45 at the time of this writing), if you click to look at older versions, say Mason 1.44, you’ll see that no other modules have their version numbers changed.
I don’t think I want to allow extensions without version numbers on PGXN. That’s been a recipe for many annoyances with CPAN. But maybe I should allow extension version numbers to repeat? The upside is less maintenance for multi-extension distribution authors. The downside is potentially less accuracy in the determination of prerequisites.
For example, say that we have two versions of distribution foo:
-----------------------------------------------------------------------------
Distribution Extensions
-------------------------------------- --------------------------------------
foo 1.2.2 foo 1.2.2\
bar 1.2.2
foo 1.2.3 foo 1.2.3
bar 1.2.2
Note how the version number of extension bar has not changed between releases. But if I was a user of both foo and bar, and I specified that I required bar 1.2.2 but was actually using stuff in foo 1.2.3, I could end up with errors because I would only have foo 1.2.3.
This is an issue periodically faced by Perl hackers. I might require HTML::Mason::ApacheHandler 1.69 but really what I need is HTML::Mason 1.44. Of course, as a Perl hacker, it’s my responsibility to make sure I require exactly what I need, but sometimes it’s not clear what’s the primary module in a distribution. And if I don’t realize that the version number of HTML::Mason::ApacheHandler doesn’t change with every release, I might make mistakes.
Maybe that’s okay. Maybe PGXN should be less rigid like this. But I’m leaning toward keeping things as they are and requiring new versions of every extension in every upload of a distribution. It’s a bit tougher for those (few?) hackers who will create multi-extension distributions, but probably more reliable for everyone else.
What do you think?
Anyway, I’m getting to work on the Web app this week while this issue percolates. Been studying up on Plack. So nice!
]]>First, the /dist directory will be the same as before. Releases of pgTAP
would be in:
dist/p/pg/pgtap/pgtap-0.23.pgz
dist/p/pg/pgtap/pgtap-0.23.json
dist/p/pg/pgtap/pgtap-0.23.readme
dist/p/pg/pgtap/pgtap-0.24.pgz
dist/p/pg/pgtap/pgtap-0.24.json
dist/p/pg/pgtap/pgtap-0.24.readme
dist/p/pg/pgtap/pgtap-0.25.pgz
dist/p/pg/pgtap/pgtap-0.25.json
dist/p/pg/pgtap/pgtap-0.25.readme
The only change is that the pgtap.json symlink is gone.
Now, the new stuff. In the root directory will be a file, index.json, that
contains templates for URIs. It will look something like this:
{
"dist": "/dist/$a/$ab/$dist/$dist-$version.pgz",
"readme": "/dist/$a/$ab/$dist/$dist-$version.readme",
"meta": "/dist/$a/$ab/$dist/$dist-$version.json",
"by-dist": "/by/dist/$a/$ab/$dist.json",
"by-extension": "/by/extension/$a/$ab/$extension.json",
"by-owner": "/by/owner/$a/$ab/$owner.json",
"by-manager": "/by/manager/$a/$ab/$manager.json",
}
The PGXN client will always fetch this file before it does anything else, because the file tells it how to find stuff. The advantage here is that the client doesn’t have to know anything about how the directory is actually organized, just what the template variables might be. They are:
$dist: A distribution name$version: A version number$extension: An extension name$owner: An owner’s name$manager: A release manager’s name (managers are the people who upload
distributions to PGXN)$a: The first letter of a distribution, extension, owner, or manager name.$ab: The first two letters of a distribution, extension, owner, or manager
name.I’m not thrilled about using prefix-staggering to avoid having too many files
in a directory. But the truth is that this approach allows me to punt. I could
also make sure the client supports, for example, $bc and $cd, so that one
could stagger things differently. And then the nice thing is that I don’t have
to use those at all. The templates will tell the client exactly how to
construct the URIs for things, and the templates needn’t include those
staggering variables if they’re not appropriate. The client won’t care because
it will have no built-in knowledge of how things are organized. It will have
to find out from index.json.
From the URI templates, you can now see where the other metadata will be stored. For extension names, a hypothetical pgTAP distribution with two extensions will have a JSON file for each extension:
/by/extension/p/pg/pgtap.json
/by/extension/s/sc/schematap.json
The pgtap.json file will look something like this:
"stable": "0.25.0",
"testing": "0.26.0b1",
"unstable": "0.30.0u",
"versions": {
"0.26.0b1": { "dist": "pgtap", "version": "0.26.0b1", "status": "testing" },
"0.30.0u": { "dist": "pgtap", "version": "0.30.0u", "status": "unstable" },
"0.25.0": { "dist": "pgtap", "version": "0.25.0", "status": "stable" },
"0.24.0": { "dist": "pgtap", "version": "0.24.0", "status": "stable" },
"0.25.0": { "dist": "pgtap", "version": "0.23.0", "status": "stable" }
}
Right at the top, it would always list the most recent stable, testing, and unstable version number, and then it would have a list metadata for all versions. Said metadata would include the associated distribution name, version, and release status.
Here’s how it would work. Say I ask the client to install pgtap:
PGXN> install extension pgtap
The client would first fetch /index.json, then look for the URI template for
“by-extension”, which is /by/extension/$a/$ab/$extension.json. Filling in
the template, it would know to request /by/extension/p/pg/pgtap.json. With
that file, it would see that the most recent stable version is in the “pgtap”
distribution version 0.25.0. Using the dist URI template, which is
/dist/$a/$ab/$dist-$version.pgz, it would then fetch
/dist/p/pg/pgtap/pgtap-0.25.0.pgz.
The advantage here is that there are no symbolic links and no knowledge of the
directory structure built into clients. The client just knows to fetch
/index.json and then to use the templates in that file to fetch other
information. That’s the whole interface. Very RESTful.
The structure of the other /by files would be similar. For
PGXN> install dist pgtap
the client would use the “by-dist” URI template to construct the URL
/by/dist/p/pg/pgtap.json. That file would have something like:
"stable": "0.25.0",
"testing": "0.26.0b1",
"unstable": "0.30.0u",
"versions": {
"0.26.0b1": "testing",
"0.30.0u": "unstable",
"0.25.0": "stable",
"0.24.0": "stable" ,
"0.23.0": "stable"
}
So then the client would know that “0.25.0” was the most recent version, and
use the dist URI template to request /dist/p/pg/pgtap/pgtap-0.25.0.pgz.
If The client command had been:
PGXN> readme dist pgtap
It would use the readme URI template. And the command:
PGXN> meta dist pgtap
Would use the meta URI template to fetch the metadata for the distribution.
If the client had requested a specific version:
PGXN> install dist 0.23.0
It could either use the by-dist URI template to download the list of all
versions to see if 0.23.0 was valid, or just use the dist URI template to
try to download the distribution itself.
And finally, the owner and manager JSON files, such as
/owner/t/th/theory.json
Would look something like:
"full_name": "David Wheeler",
"email": "theory@pgxn.org",
"uri": "https://justatheory.com",
"distributions": {
"pgtap": [ "0.25.0", "0.24.0", "0.23.0" ]
"pair": [ "0.2.0", "0.1.0", "0.0.5" ]
}
With that, the client can be asked to fetch metadata for a given owner name and use it to figure out what distributions and versions the the owner, um, owns. One could then fetch the metadata, readme, or distribution file for any of those distributions and versions.
Overall, I think that this is a much better solution than I outlined before. If only I could figure out something more elegant that the prefix-staggering/hashing stuff, it would be just about perfect.
Thoughts?
]]>The first two are a bit mutually-contradicting. Thinking scalability mainly
means minimizing the chances that too many files can be put into a single
directory. CPAN started out with all author directories in a single
directory. Given the sheer number of CPAN contributors, this quickly got to be
a bottleneck. To correct for that, they started “hashing” the first two
letters of author names to create subdirectories. My CPAN directory, for
example, is D/DW/DWHEELER. That doesn’t quite make for an intuitive
location, but it’s not bad, and the tradeoff seems sufficient to keep things
sane.
The first two are a bit mutually-contradicting. Thinking scalability mainly
means minimizing the chances that too many files can be put into a single
directory. CPAN started out with all author directories in a single
directory. Given the sheer number of CPAN contributors, this quickly got to be
a bottleneck. To correct for that, they started “hashing” the first two
letters of author names to create subdirectories. My CPAN directory, for
example, is D/DW/DWHEELER. That doesn’t quite make for an intuitive
location, but it’s not bad, and the tradeoff seems sufficient to keep things
sane.
The storage of metadata is important, too, as I plan to have the client send requests for JSON files to mirrors in order to find distributions. Basically, this came down to a naming convention, as well as a recipe for how to find metadata files for people and extensions. What I’ve come up with is three directories:
meta will contain PGXN metadatadist will contain distributionsby will contain query-able JSON filesThe meta directory will contain PGXN metadata (mirrors.json, timestamp,
other detritus). If I ever create an index file that lists all distributions,
it would go there, too. I’m not going to discuss it any further here, except
to note that it already has mirrors.json, which clients will be able to use
to present users with a list of mirrors to choose from.
The dist directory will be organized with directories named with “hashes” of
the first two letters of distribution names. Let’s say that I’m releasing
pgTAP 0.25 on PGXN. To distribute it, the management application will create
the directory (if it doesn’t already exist):
dist/p/pg/pgtap/
Then, for the 0.25 release, it will add three files to that directory:
dist/p/pg/pgtap/pgtap-0.25.pgz
dist/p/pg/pgtap/pgtap-0.25.json
dist/p/pg/pgtap/pgtap-0.25.readme
The pgtap-0.25.pgz file will contain the zipped distribution ready for
download. pgtap-0.25.json will contain metadata about the distribution, such
as the owner’s name, the manager’s name (more on these folks below), list of
included extensions, location of the .pgz and .readme, and its SHA1.
pgtap-0.25.readme will of course contain the README for the distribution
(if it has one).
Every release of pgTAP will have these three files, so after several releases,
the pgtap directory might have these files:
dist/p/pg/pgtap/pgtap-0.23.pgz
dist/p/pg/pgtap/pgtap-0.23.json
dist/p/pg/pgtap/pgtap-0.23.readme
dist/p/pg/pgtap/pgtap-0.24.pgz
dist/p/pg/pgtap/pgtap-0.24.json
dist/p/pg/pgtap/pgtap-0.24.readme
dist/p/pg/pgtap/pgtap-0.25.pgz
dist/p/pg/pgtap/pgtap-0.25.json
dist/p/pg/pgtap/pgtap-0.25.readme
dist/p/pg/pgtap/pgtap.json
The last file there, pgtap.json, will actually be a symlink to the JSON file
for latest production release of pgTAP. In this case, it would link to
pgtap-0.25.json. The nice thing about this is that, if a client wants to
find the information about the latest release of the pgtap distribution, all
it will have to do is send an HTTP GET request for
dist/p/pg/pgtap/pgtap.json to any mirror.
The by directory will also contain JSON files for clients to request. The
idea is that you want to find information “by” something. To start with, there
will be three subdirectories:
by/extension/
by/manager/
by/owner/
The first directory, by/extension/, will contain links to JSON files for
extensions. Say that the pgTAP distribution offers two extensions to
PostgreSQL named “pgtap” and “schematap”. The links would be:
by/extension/p/pg/pgtap/pgtap-0.23.json
by/extension/p/pg/pgtap/pgtap-0.24.json
by/extension/p/pg/pgtap/pgtap-0.25.json
by/extension/p/pg/pgtap/pgtap.json
Each of these will simply be symlinks pointing to the appropriate distribution files:
dist/p/pg/pgtap/pgtap-0.23.json
dist/p/pg/pgtap/pgtap-0.24.json
dist/p/pg/pgtap/pgtap-0.25.json
dist/p/pg/pgtap/pgtap.json
Yes, the last one is a symlink to a symlink. Similarly, these files for “schematap”:
by/extension/s/sc/schematap/schematap-0.23.json
by/extension/s/sc/schematap/schematap-0.24.json
by/extension/s/sc/schematap/schematap-0.25.json
by/extension/s/sc/schematap/schematap.json
Point to exactly the same files. Essentially, this is a way for extensions to
point to the distributions that contain them.
by/extension/s/sc/schematap/schematap.json points to
dist/p/pg/pgtap/pgtap.json, which contains path to the .pgz file to
download (and lots of other metadata, too).
The idea is that, whatever the name of the extension you want, the client will be able to easily find the metadata file that tells it where to find the distribution.
The by/manager and by/owner directories, on the other hand, contain JSON
files with information about managers and owners and their distributions.
Definitions:
An “owner” is someone who owns a distribution. This will often be the original author of an extension, but may be someone else if maintenance has been passed on. Basically, the “owner” is the person who should be contacted with bug reports and the like
A “manager” is someone who manages the release process. This is the user who will log into the PGXN management application and upload a distribution for release.
These two people will often be the same person, but not always. I’ve avoided the term “author” (the term used by CPAN) because the author of an extension may no longer maintain it. “Owner” seemed like a better choice (individual distributions are free to describe their contributors however they wish).
As the owner of a few extensions on PGXN, I’d have this file:
by/owner/t/th/theory.json
This file would contain a list of my distributions and perhaps some other information (like my full name and blog URL).
As the manager of extensions on PGXN (that is, I actually uploaded them), I would also have:
by/manager/t/th/theory.json
This file would contain a list of the distributions I’ve released on PGXN. This might be exactly the same as the list in my owner file, but may not be. Perhaps for one release of pgTAP, say 0.26, Duke Leto uploaded a release. In that case, 0.26 would probably be in my owner file, but not in my manager file: it would be in Duke’s manager file, instead.
So these are the basics of the directory structure for the networked mirrors. Note that I haven’t thought much about everything that will go into the JSON files (or whether or not they’d be versioned). That will likely depend quite a lot on what the management database ends up looking like. I’ll be working on that next.
But other than that, comments? Questions? Criticisms? Recommendations? Leave a comment and let me know!
]]>