- From: Ben De Meester <ben.demeester@ugent.be>
- Date: Wed, 9 Mar 2016 09:09:51 +0100
- To: Mike Perlman <perlmanm@me.com>
- Cc: Ivan Herman <ivan@w3.org>, Leonard Rosenthol <lrosenth@adobe.com>, W3C Digital Publishing IG <public-digipub-ig@w3.org>
- Message-ID: <CAJ-O9TsXHbJE_fAnmcVMNjVowYntZoW80Bzn5GkD0KaHaK=rrA@mail.gmail.com>
Leonard, am I correct in thinking that you are aiming at the fact(s) that - a server will always need a minimal configuration (so, even in its simplest form, the server needs to perform a minimal amount of processing), but might be a lot more complex to allow for more complex functionalities on the server-side? - This extra functionalities could make the client-side processing more efficient, for example, being able to retrieve a resource within a packed PWP at the server-side, so that the client doesn't have to unpack the PWP locally. - Our model should not (and I don't think it currently does) disallow the fact that this server might be more complex. Maybe, the definitions at http://w3c.github.io/dpub-pwp-loc/#dfn-pwp-processor and http://w3c.github.io/dpub-pwp-loc/#dfn-server are sufficient, but an extra section is needed to further clarify this? What do you think? Am I missing something? Ben Ben De Meester Researcher Semantic Web Ghent University - iMinds - Data Science Lab | Faculty of Engineering and Architecture | Department of Electronics and Information Systems Sint-Pietersnieuwstraat 41, 9000 Ghent, Belgium t: +32 9 331 49 59 | e: ben.demeester@ugent.be | URL: http://users.ugent.be/~bjdmeest/ 2016-03-09 8:45 GMT+01:00 Mike Perlman <perlmanm@me.com>: > 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> wrote: > > > 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 > <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 > > 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 > > > > > >
Received on Wednesday, 9 March 2016 08:10:43 UTC