FsfLicenseDataParser: Fill in implementation #112
Conversation
wking
force-pushed
the
fsf-libre-parser
branch
from
a0027d2 to
47f1a90
Compare
Pull the index (mapping from SPDX IDs to FSF IDs) during initialization, and then lookup each license as needed with a separate request. An implementation that hits isSpdxLicenseFsfLibre multiple times (or which wanted to extract multiple values for a single license) would be more efficient if we cached the per-license FSF response. I've left that off for now because our only consumer is just asking for libre-ness, and only doing that once per license. I've used a Boolean for the isSpdxLicenseFsfLibre to get a nullable value, so we can represent: * "yes, the FSF marks that license 'libre'" (true), * "no, the FSF considers that license non-free" (false), and * "we don't know the FSF opinion for that license" (null).
|
@wking After reviewing the pull request, we are going to do a file open on every isFsfLibre request which introduces performance and additional possibilities of errors. I also have implemented features in the SPDX tools to work offline, so we would need to add an offline cache of the FSF API. This is much easier to implement and keep in sync as a single file. I understand the desire to have a "clean" implementation of an API, but the same argument could even be made for storing the SPDX ID. That being said, my opinion is that we should include the flag in the index for practical reasons. Can you describe any practical issues with including the flag in the index (e.g. performance or maintenance issues)? And do you believe these issues outweigh the practial issues with not including the information in the index? There are several examples of indexes and file system directory structures where metadata is stored in the index itself. One other consideration, the FsfLibre is a core piece of FSF information and, in my opinion, the main reason for the FSF list. Therefore it should be included in the index. |
There was a problem hiding this comment.
I would like the libre flag to be cached, ideally populated in the constructor so we don't have to open a file on every flag request.
We would also need to support the tool running offline. This can be done by copying a copy of the JSON files to the resources folder and accessing the files if the website is not available (see the ListedLicenses as an example).
|
On Thu, Oct 26, 2017 at 11:23:57AM -0700, goneall wrote:
I understand the desire to have a "clean" implementation of an API,
but the same argument could even be made for storing the SPDX ID.
Agreed, which is why I've floated wking/fsf-api#6 to drop it from the
index ;).
Can you describe any practical issues with including the flag in the
index (e.g. performance or maintenance issues)?
Can we have this discussion in wking/fsf-api#1, where it will be
separate from this particular implementation?
|
Moved conversation to wking/fsf-api#1 |
Pull the index (mapping from SPDX IDs to FSF IDs) during initialization, and then lookup each license as needed with a separate request.
An implementation that hits
isSpdxLicenseFsfLibremultiple times (or which wanted to extract multiple values for a single license) would be more efficient if we cached the per-license FSF response. I've left that off for now because our only consumer is just asking for libre-ness, and only doing that once per license.I've used a Boolean for the
isSpdxLicenseFsfLibreto get a nullable value, so we can represent:true),false), andnull).Related discussion in wking/fsf-api#1 and wking/fsf-api#5.
And this may be my first Java ever, so please review carefully and don't assume I know what I'm doing ;).