Re: [dpub-loc] meeting

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:05:49 UTC