- From: Leonard Rosenthol <lrosenth@adobe.com>
- Date: Wed, 9 Mar 2016 14:03:53 +0000
- To: Ivan Herman <ivan@w3.org>
- CC: Ben De Meester <ben.demeester@ugent.be>, W3C Digital Publishing IG <public-digipub-ig@w3.org>
- Message-ID: <8E12B873-D8BC-49F4-B76D-A8281C3E505F@adobe.com>
Long is perfectly fine – we definitely need to resolve this… > The role of the PWP Processor is, in my view, to provide a separation between the PWP rendering layer and handling the various states > I agree with that completely. > The role of the PWP processor is fulfilled by providing some sort of a "translation" between this ideal world and the real world> > Also in complete agreement. > It is correct that, in this definition of the PWP Processor, it is not necessarily running in a client only. >It is perfectly possible to implement a PWP Processor by pushing part of its functionality to a (possibly third party) server, >and keeping only part of its functionality in a client > And for three in a row, I also agree completely. > the PWP Processor is cut into a number of internal processors communicating among them in some implementation specific manner > BUT here is where we disagree. There is NOTHING implementation specific about the server side implementation. The server could be simply providing “dynamic (or transparent) unpacking” and the client would be none the wiser, and thus work exactly according to the diagram. But because the server happens to be doing some of the PWP Processing the client is relieved of some of its duties. But the client doesn’t change. > there is no separate "server side" PWP processor to be described > Back to agreement :). I agree with that, but as you say in the third paragraph above the PWP Processor can live in one of three places (client, server, both). And that isn’t what the current text reads – it says the PWP Processor is client only. Just remove that piece about client=side only, and I think we are OK. >I would certainly add a note referring to a client side processor as the most likely implementation strategy. > I would not support that. I realize that you are coming at this from a client-side perspective, but my company (and my view) is BOTH sides. We have a major cloud/server-side business as well as a client-side (browser and other) one. Both sides are important to us and, we believe, the entire PWP strategy and therefore both need equal representation. Leonard From: Ivan Herman <ivan@w3.org<mailto:ivan@w3.org>> Date: Wednesday, March 9, 2016 at 8:30 AM To: Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>> Cc: Ben De Meester <ben.demeester@ugent.be<mailto:ben.demeester@ugent.be>>, W3C Digital Publishing IG <public-digipub-ig@w3.org<mailto:public-digipub-ig@w3.org>> Subject: Re: [dpub-loc] meeting Leonard (Sorry for the longish response) All this may be a terminological issue... let us see. The role of the PWP Processor is, in my view, to provide a separation between the PWP rendering layer and handling the various states a PWP can be in. Ie, the rendering part has a relatively simple 'view' of the world: it considers a PWP *as if* it was a pure, traditional Web site, i.e., a collection of Web Resources accessed through HTTP(S), using the canonical URL as "the" base locator. Ie, as if the PWP was in an unpacked and protocol states, to use the terminology in the current PWP draft<http://w3c.github.io/dpub-pwp/#state_definition>. The role of the PWP processor is fulfilled by providing some sort of a "translation" between this ideal world and the real world. It retrieves the information from a server in some format and, through some specific locators, possibly unpacks data on the fly, caches the content if needed, translates among locator values, etc. The diagram describes what the processor expects to receive through the usual HTTP(S) channels to set up what it needs for processing (essentially the mapping of URL-s). It is correct that, in this definition of the PWP Processor, it is not necessarily running in a client only. It is perfectly possible to implement a PWP Processor by pushing part of its functionality to a (possibly third party) server, and keeping only part of its functionality in a client. In that case the PWP Processor is cut into a number of internal processors communicating among them in some implementation specific manner, but that is a purely implementation specific issue, and it is not up to a PWP specification to define the modalities. In this sense you are right that a PWP Processor is not necessarily bound to a client; the description should make this clearer (essentially by not formally referring to client or server side). But I do *not* think there is anything else to be defined through a PWP specification; there is no separate "server side" PWP processor to be described. All that being said, I think that, realistically, the implementation of a PWP Processor would happen primarily on the client-side. I also believe that, conceptually, it is perfectly fine to look at a PWP Processor as a client side entity: that makes it clearer and probably easier to grasp for people even if, on the formal specification level, the Processor is indeed not strictly bound to a client. Ie, the text have to be made clearer or more "pure", although I would certainly add a note referring to a client side processor as the most likely implementation strategy. (There is an analogy. There are browsers, e.g., Opera Mini, which does a slightly unusual way of processing: when an HTTP request comes from the user, it would not retrieve that resource from the Web like the usual browsers; instead, it communicates to a specific server that would do the HTTP communication on its behalf, cache the result and send back to the client some sort of an optimized, processed version of the content. Conceptually, Opera Mini behaves just like any other browser; this internal, extra server-client layer is not something the definition of a browser would or should care about...) Ivan On 9 Mar 2016, at 13:44, Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>> wrote: Why does the specification only concern itself with the client? We are describing a processor – where that processor lives should not be relevant. BUT since we are describing a client-side design, we should also be providing for a server-side one as well. I do agree with you that the model/nature of the server-side PWP processor is different than the client side – which is why we need to describe it! And it is more than just server-side configuration, it would be actual code running on the server. Which is perfectly acceptable, even if you don’t want it for your own setups. Leonard From: Ivan Herman <ivan@w3.org<mailto:ivan@w3.org>> Date: Wednesday, March 9, 2016 at 12:46 AM To: Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>> Cc: Ben De Meester <ben.demeester@ugent.be<mailto:ben.demeester@ugent.be>>, W3C Digital Publishing IG <public-digipub-ig@w3.org<mailto:public-digipub-ig@w3.org>> Subject: Re: [dpub-loc] meeting On 9 Mar 2016, at 00:55, Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>> wrote: I am not fine with it. A PWP Processor could be either client or server or both. It needs to be clear that our design supports all of these modes. We have discussed this and we seem to be in a disagreement. A possible PWP specification describes, normatively, the behaviour of what happens on the client side. That is the PWP processor there. It should not describe/prescribe what happens on the server side. It may provide possible alternatives on how the information, as described *for the PWP Client side processor*, can be provided, it can provide good practices and examples, server configurations, etc, but it has a fundamentally different nature than the client side specification. Calling that server side a PWP processor would be misleading and, imho, wrong. We have a PWP Client Process, and we may have some best practices for server setup. Ivan Leonard From: Ivan Herman <ivan@w3.org<mailto:ivan@w3.org>> Date: Tuesday, March 8, 2016 at 12:08 PM To: Ben De Meester <ben.demeester@ugent.be<mailto:ben.demeester@ugent.be>> Cc: W3C Digital Publishing IG <public-digipub-ig@w3.org<mailto:public-digipub-ig@w3.org>> Subject: Re: [dpub-loc] meeting Resent-From: <public-digipub-ig@w3.org<mailto:public-digipub-ig@w3.org>> Resent-Date: Tue, 8 Mar 2016 17:09:12 +0000 On 7 Mar 2016, at 15:08, Ben De Meester <ben.demeester@ugent.be<mailto:ben.demeester@ugent.be>> wrote: Hi all, The next locators TF meeting will be on March 9th at 1500 UTC [1] I have made a first draft of the locators work until now (http://w3c.github.io/dpub-pwp-loc/), basically combining all text that we already agreed on, and adding issues where consensus is to be reached. Thanks! Most important change between what we discussed until now and the doc is that I currently call the Server-side PWP processor just the `server`, to (try to) avoid confusion. So a PWP processor is always assumed client-side. If there are any suggestions for better naming, please let me know :). I am, personally, fine with this... Agenda: * Going over currently open issues of the doc, finding new issues. It would be great if we could use the github issue-system (https://github.com/w3c/dpub-pwp-loc/issues) to open new issues, so any comments on the doc: please open a new github issue! :) Actually, I think we should "transfer" the issues listed in the document into the github issue list; it would help us to manage them. That could also help in reducing the big rosy blobs in the current document by just, essentially, referring to the issues in github, thereby making the document more readable… If you agree, I may find some time tomorrow doing this. Unless you beat me into it:-) Ivan Kind regards, and hear you on Wednesday! Ben [1] http://www.timeanddate.com/worldclock/fixedtime.html?msg=DPUB+Locators&iso=20160309T15<http://www.timeanddate.com/worldclock/fixedtime.html?msg=DPUB+Locators&iso=20160210T15> IRC: #dpub-loc Topic: DPUB IG Locator Task Force Date: Every Wednesday, from Wednesday, January 13, 2016, to Wednesday, December 21, 2016 Time: 10:00 am, Eastern Standard Time (New York, GMT-05:00) Meeting Number: 640 269 372 Meeting Password: Please obtain your meeting password from your host. ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://mit.webex.com/mit/j.php?MTID=mec073df570c69d4340ca47564e81b37a 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: Please obtain your meeting password from your host. 4. Click "Join". To view in other time zones or languages, please click the link: https://mit.webex.com/mit/j.php?MTID=maa411ca7bcf238f6c25818c4ef58f654 ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting, or call the number below and enter the access code. US Toll Number: +1-617-324-0000<tel:%2B1-617-324-0000> Access code:640 269 372 Mobile Auto Dial:+1-617-324-0000<tel:%2B1-617-324-0000>,,,640269372# ---- Ivan Herman, W3C Digital Publishing Lead Home: http://www.w3.org/People/Ivan/ mobile: +31-641044153 ORCID ID: http://orcid.org/0000-0003-0782-2704 ---- Ivan Herman, W3C Digital Publishing Lead Home: http://www.w3.org/People/Ivan/ mobile: +31-641044153 ORCID ID: http://orcid.org/0000-0003-0782-2704 ---- Ivan Herman, W3C Digital Publishing Lead Home: http://www.w3.org/People/Ivan/ mobile: +31-641044153 ORCID ID: http://orcid.org/0000-0003-0782-2704
Received on Wednesday, 9 March 2016 14:04:25 UTC