Review Comment:
Changes from the previous version include a few minor clarifications and changes in wording throughout the paper as well as the following:
Abstract
- no change
1. Introduction
- addition of two paragraphs introducing the presented tool
2. Preliminaries & Related Work
- addition of "Preliminaries" in the section title
- slight extension of 2.3 Existing implementations, now mentioning the Nextcloud plugin
3. Use Cases
- clarified that the use cases were derived from discussion with community members
4. Requirements
- at end of each subsection: addition of single sentence naming the use cases from which the requirement was distilled from
5. Architecture
- no change (other than wording)
6. Configuration
- added a paragraph on the choice of programming language
- replaced example configuration listing with overview table of available default configurations
7. Sustainability, Usage & Impact
- slight extension of 7.1 Sustainability on what the term means (reliable, maintainable and specification conformant) as well as clarification on the applied test strategy
- addition of a particular sentence in 7.3 Community impact claiming that the tool is used by some institutions without reference
- slight extension of 7.4 Supporting people who use the server, a paragraph on logging and a paragraph on GUI
8. Conclusion
- no change (other than wording)
Appendix
- Addition of Appendix A for term definitions.
---
Revisiting critique of the previous version
"The paper does not clearly define terminology that is used throughout the paper."
Addressed by Appendix A. However, Appendix A is never referenced from the text.
I ask the authors to point towards the Appendix sufficiently early.
I would encourage the authors to link to the corresponding specifications of defined terms, e.g. resource, container, WebID, Identity Provider, ...
"The paper does not clearly establish connections between the contents of single sections (e.g. sections 3 and 4, or sections 5 and 6)"
Partially addressed by the addition of the subsection sentences in Section 4.
However, the requirements are not directly referenced in the following sections but are only implicitly covered, e.g. logging in Section 7.4, modularity in Section 6.
Maybe the authors could add phrases such as "addressing Requirement 1,2,3 ..., " to be more explicit on how their requirements are covered.
"The paper does not clearly delineate what is "just" implementation of the Solid Protocol and what are (software) architectural design choices to provide the tool's main value."
I am still not convinced that a reader unfamiliar with the Solid Protocol is able to distinguish what is simply implementation of specification by the CSS and what is a design decision that makes the CSS so modular and thus useful.
I encourage the authors to clearly state in a dedicated preliminary section what the Solid Protocol specifies, and to clearly explain the design choice (interfaces, data flow etc) made while implementing it in the CSS.
"2. The authors may want to consider moving section 2.1 and 2.2 into a Preliminaries section ..."
I am afraid that adding the term Preliminaries to the Section title does not addressed this issue properly.
I encourage the authors to provide a stand-alone preliminaries section and a stand-alone related work section.
"3. The use cases read like artificial user stories."
I appreciate that the authors clarify that the use cases were derived from community discussion.
Still, I was hoping for some link or reference to specific community discussions as the tool is called the "Community" Solid Server.
In addition, it remains unclear how this requirement was "distilled" from the mentioned use case.
"5. The authors could improve the architecture section by explaining how their software design choices result in the claimed modularity."
This has not been addressed and remains a major issue from my perspective.
"6. I see two parts in this configuration section: First an introduction to Components.js, which could also be a short section in a preliminaries chapter. [...] I would have expected in Section 5 to see a UML diagram that presents these components and how they relate to each other in the architecture."
I appreciate the authors presenting an overview of the default configurations.
However, I am still missing a description on how the single elements of the configuration map to the architecture presented in Section 5. How are "accounts, https, subdomains and quota" related to the architecture?
"7. [...] do the authors know of any projects or institutions using the CSS for R&D purposes as outlined?"
I appreciate the authors adding a sentence on which institutions use the CSS.
I encourage the authors to add references to their claims or links to deployed instances.
---
Closing thoughts
Similar to previous version's reviewer 2, I appreciate the tool itself and acknowledge its impact and importance in the community.
However, I still see major issues in the architectural description of the tool (issue with Sections 5 and 6) which has not been addressed in this version.
In particular, I lament the lack of a stand-alone preliminaries section on the Solid Protocol and a clear explanation of the design choice (interfaces, data flow component between software components) while implementing the Solid Protocol in the CSS.
Nonetheless, I think that this tools report can be a useful contribution to the community once the mentioned issues are addressed.
| 
