search

solid / specification

Solid Technical Reports
https://solidproject.org/TR/
MIT License
472 stars 42 forks source link

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

Open elf-pavlik opened 11 months ago

elf-pavlik commented 11 months ago

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

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

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 commented 11 months ago

+1 for Resource Server

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

csarven commented 11 months ago

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 https://github.com/solid/specification/issues/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 commented 11 months ago

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 commented 11 months ago

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 commented 11 months ago

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 https://github.com/solid/solid-wg-charter/issues/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.