Re: [dpub-loc] meeting

The relevance is the possibility for a server-side “component” (be it code, configuration, etc.) to aid the client by doing such things as unpacking, dynamic translation, etc.

As described in Ivan’s diagram, the clients needs the manifest and it requests it.  The server responds to that request – but we say NOTHING about what the server might do to help the client with that request.  Sure, you could have a dumb server that just returns a packed version of the PWP (assuming that is how it is stored on the server) and make the client do all the work.  BUT you could just as easily have a smart server that knows how to reach into a PWP (just as some know how to reach into ZIPs, etc.) and return the manifest directly.

Leonard

From:  Mike Perlman <perlmanm@me.com<mailto:perlmanm@me.com>>
Date: Wednesday, March 9, 2016 at 2:45 AM
To: Ivan Herman <ivan@w3.org<mailto:ivan@w3.org>>
Cc: Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>>, 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

I don’t understand the relevance of server-side processing to PWP.
The PWP loads in a user’s browser. If for some reason it needs to retrieve something from somewhere else, it gets it if the user is online.
These should be requests for static data - media, text, whatever.
But the processing is still local.

On 09 Mar 2016, at 06:46, Ivan Herman <ivan@w3.org<mailto:ivan@w3.org>> wrote:


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

Received on Wednesday, 9 March 2016 12:49:06 UTC