Re: [dpub-loc] meeting

Thank you Ben :)
(sorry for losing this info)

On Wed, Mar 9, 2016 at 3:04 PM, Daniel Weck <daniel.weck@gmail.com> wrote:
> Hello all, could someone kindly remind me the name of the IRC channel,
> and the WebEx password? (off list)
> Thank you very much.
> Daniel
>
> On Wed, Mar 9, 2016 at 2:57 PM, Ivan Herman <ivan@w3.org> wrote:
>>
>> On 9 Mar 2016, at 15:03, Leonard Rosenthol <lrosenth@adobe.com> wrote:
>>
>> 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.
>>
>>
>> And I do not understand what you want to describe. Conceptually, the
>> client+server combination is one single entity. The PWP Processor is one,
>> regardless of where it runs and how it is implemented. As I said, you are
>> right that we should not say whether the PWP Processor is client or not, but
>> then there is nothing to be said of a server either...
>>
>>
>>
>>> 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.
>>
>>
>> Right. That is what I said: the PWP Processor behaviour should be described
>> so that it is agnostic whether it is client, server, or a combination of the
>> two.
>>
>>
>>>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.
>>
>>
>> O.k. Maybe, as part of an informative part, we can describe various
>> strategies, but not as part of the core functional description.
>>
>> I.
>>
>>
>>
>> Leonard
>>
>> From: Ivan Herman <ivan@w3.org>
>> Date: Wednesday, March 9, 2016 at 8:30 AM
>> To: Leonard Rosenthol <lrosenth@adobe.com>
>> Cc: Ben De Meester <ben.demeester@ugent.be>, W3C Digital Publishing IG
>> <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.
>>
>> 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> 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>
>> Date: Wednesday, March 9, 2016 at 12:46 AM
>> To: Leonard Rosenthol <lrosenth@adobe.com>
>> Cc: Ben De Meester <ben.demeester@ugent.be>, W3C Digital Publishing IG
>> <public-digipub-ig@w3.org>
>> Subject: Re: [dpub-loc] meeting
>>
>>
>> On 9 Mar 2016, at 00:55, Leonard Rosenthol <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>
>> Date: Tuesday, March 8, 2016 at 12:08 PM
>> To: Ben De Meester <ben.demeester@ugent.be>
>> Cc: W3C Digital Publishing IG <public-digipub-ig@w3.org>
>> Subject: Re: [dpub-loc] meeting
>> Resent-From: <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> 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
>>
>> 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
>>
>> Access code:640 269 372
>> Mobile Auto Dial:+1-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
>>
>>
>>
>>
>>
>>
>> ----
>> 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 15:12:23 UTC