On Fri, Oct 18, 2019 at 9:31 PM Chris Angelico wrote:
> You mention a persistent Storage, merely in passing. I want to see
> more about that. If that storage format is a nice easy thing to work
> with (eg a set of JSON files), and is a documented and
> forward/backward-compatible format, it could become a de facto
> interchange format.
Not defining Storage is intentional. Since the application is layered Storage
may take any form you want as long as Fetcher and Reader agree on what it is.
Currently implemented Fetcher and Reader for GitHub issues use JSON files for
Storage. The format is almost the same as raw API response (the only added key
is timestamp that API returns via HTTP headers).
That does not mean all Fetchers and Readers have to use the same format.
Someone else might want to store data in SQLite file, another person would
like MongoDB instance - all is possible if they write their own Fetcher and
Reader for such Storage (Issyours provides base class for Reader that
simplifies adding support new storage mechanisms).
In fact, you might even not need to implement the Fetcher to add another data
source - some issue trackers already provide "Export all my data" mechanisms.
In that case only Reader must be created.
I've chosen this approach because I think it's almost impossible to create a
storage format that would become "a de facto interchange format". At least not
for a project run by a single developer. Defining an agreeable dataset for
visual representation is easier because it does not impose any limits on those
who want to store extra data - they get to store anything they want any way
they want. The limitations apply only to the presentation layer. If they don't
like my approach - their data is still intact, in machine readable format.
> What are the consequences of using the AGPL for this? If this project
> is used to create a viewable/searchable issue display, does that mean
> that the issues themselves are covered by the AGPL, or are they
> counted as data?
Oh, no! Of course issues and comments are data and are not covered by AGPL.
Only the application itself is covered, even though AGPL for a static site
generator is almost unenforceable, because of the middleware loophole.
Pelican - static site generator I base my work on - uses AGPL for their source
code, and no one is going around claiming all the blog posts are now copyleft.
--
https://mail.python.org/mailman/listinfo/python-list
