Server-side operations

[w3c]

Server-side operations

[iherman]

Well… the discussion is still pending, so we may see where it goes. However, at this moment, I do not fully agree with what you propose.

If this was a specification, I would say that there should be a separate, non-normative section in the document that talks about some of these options on how the server set up may be done. But that should not be part of the the definition of a server for our own use.

Bottom line is:

On 9 Mar 2016, at 14:46, Ben De Meester [email protected] wrote:

As raised by @lrosenthol https://github.com/lrosenthol (https://lists.w3.org/Archives/Public/public-digipub-ig/2016Mar/0043.html https://lists.w3.org/Archives/Public/public-digipub-ig/2016Mar/0043.html)

potential definitions of the server-side operations are as valid (or potentially more so) than the client and should be present in the document as well

Proposal: change last sentence of the definition of server http://w3c.github.io/dpub-pwp-loc/#dfn-server to "This server will always need some kind of configuration or maybe more complex functionalities. The minimal requirement of a server is that when L is requested, it should return M (which in turn could be combined by using different parts of the HTTP response, see http://w3c.github.io/dpub-pwp-loc/#pwp-processor http://w3c.github.io/dpub-pwp-loc/#pwp-processor). Depending on the implemented functionalities of the server, it could take the preferences of the client-side into account (see #8 #8)".

I would not change the definition; this explanation should go to a separate section

Following example might clarify the issue (and could also be inserted in the document somewhere):

When L is requested, the server returns either the manifest, the main HTML page (to be defined what the main HTML page is), or a package, with optional HTTP Link Header (see http://w3c.github.io/dpub-pwp-loc/#pwp-processor http://w3c.github.io/dpub-pwp-loc/#pwp-processor).
This returning result depends on three factors: the preference of the client-side (see #8 #8 ), the capabilities of the server, and the published states of the PWP.

If we assume the PWP is only published zipped, and the preference of the client-side is zipped, then the server does not need any more capabilities than just returning the package.
If the preference of the client-side is the manifest, and the server is just a file server, then the server can only return the zip-package, and the client is burdened with unpacking the zip client-side and extracting the manifest.
If the server has the functionality, it could unpack the zip server-side and return the manifest directly to the client.
Vice versa and other alternative scenarios are also possible, e.g., a client requests the zipped PWP and the server only has the unpacked PWP published. depending on the capabilities of the server, either
the client is burdened with packing the PWP client-side (dumb server), or
the server packs the PWP server-side (smart server).
I do not have a problem with this, if it is put into a separate, "non-normative" section of the document.

[iherman]

For reference, see my separate mail on the subject, relevant to this issue:

http://www.w3.org/mid/[email protected]

[lrosenthol]

Removing the "this is a client side only" piece in the definition of PWP Processor shoudl resolve it.