Rename 'Server' to something more specific 'Resource Server' or 'Storage Server' or ...

[elf-pavlik]

The current product class Server doesn't really specify what role the server plays. Solid relies on more than one type of server:

• Solid-OIDC Provider (Solid-OIDC)
• Authorization Server (Solid-OIDC & [AuthN & AuthZ] Server side clients (apps) #504)
• Subscription Server (Solid Notifications)
• Notifications Sender (Solid Notifications)

As well as drafts not included in Solid Protocol v0.11

• Authorization Agent (SAI)
• WebID Provider <-- some deployments run it as a separate service and there are ongoing discussions in WebID-Profile panel

I think the closest matching term for the Server defined in the Solid Protocol would be Resource Server. It is also already used in Solid Notifications and well established by the OAuth community.

My next choice would be Storage Server since hosting solid storage is its primary (only?) responsibility.

[woutermont]

+1 for Resource Server

It's well established, and we already use it in a lot of texts.

[csarven]

Glad to hear that re-naming is coming up (again). Having detailed classes of products in the first place, and perhaps even more importantly, what they can individually interop with has been in our radar / work in progress. That's especially in the context of Solid QA and getting conformance models right. It plays an important part in identifying significant units of information in technical reports, test cases and test reports. I created #480 around the time both Solid Protocol and Solid Notifications Protocol introduced a proper Conformance section. The initiative goes beyond naming. With the example of changing "server" to "resource server", the definition of the product and all of the requirementSubjects in the specification needs to change - otherwise it is just bikeshedding. Issue 480 (for all work items) and revisiting how we approach Conformance is important.

[elf-pavlik]

In issue #480 you talk about generalizations, here I propose using more specific naming for one already defined product class: https://solidproject.org/TR/protocol#Server

Could you please clarify how do you see this issue supporting resolving #480 and vice versa?

[csarven]

What would be the point of renaming if not to better denote its definition? The point of 480 is that "server" in Solid Protocol for instance may be overloaded - it does more than "resource server" stuff upon close inspection of the requirements. If "server" can be split into resource server, authentication server, authorization server, notification server, n3-patch processor, storage, and so forth, those are all simply different classes of products across different specifications. So, I think this issue should consider aiming to name/define the significant parts of a server (as mentioned in 480), e.g., "resource server" (responding agent) as being one, as separate units (that can be built by different parties/codebases) that can interop with other classes of products defined elsewhere. The same goes for distinguishing/specifying parts of client (and application.)

[elf-pavlik]

The point of 480 is that "server" in Solid Protocol for instance may be overloaded - it does more than "resource server" stuff upon close inspection of the requirements.

I see, how about taking the first step and extracting a more specific Resource Server from the overloaded Server?

To be honest, I would actually prefer extracting Solid Storage into a separate, focused specification and having Solid Protocol only including a short section Storage. Similar to Live Update, Authentication and Authorization.
This would also result in Solid Storage having much less normative dependencies solid/solid-wg-charter#37

Either way, I would consider the step of extracting the Resource Server from Server as an acceptable resolution for this issue. #480 could track the broader issue and we could discuss extracting Solid Storage in dedicated issue as well.