W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2011

Re: copy events and content from server

From: Paul Libbrecht <paul@hoplahup.net>
Date: Tue, 17 May 2011 08:50:30 +0200
Cc: public-webapps <public-webapps@w3.org>
Message-Id: <4F3FF997-6924-41E2-B44E-F9FACE616D2A@hoplahup.net>
To: "Hallvord R. M. Steen" <hallvord@opera.com>

you seem to have not included João Eiras' answer:

Le 5 mai 2011 à 04:34, João Eiras a écrit :
> A synchronous XHR solves this use case and there are no magic locks.

Although I haven't explicitly tried to implement it and clearly feel it a synchronous XHR can block the UI in an ugly way, it can indeed be sufficient.

But, couldn't a better solution, not involving locks, be a variation of what you suggest:?

  event.clipboardData.pushDataFromRequest(flavour, xhr)

The big difference is that there is a chance for the user-agent to display that his copy action is being process. I think the flavour must stay in the hands of the script (as the map media-types -> flavors is currently very partial).

I'm surprised to be the only one pushing this considering the huge wealth of desktop-like services. Use cases such as copy-a-pdf-fragment from Google Docs Drawing, generate a complex ICS, or produce a good raster image from a graph-display...


Le 17 mai 2011 à 02:30, Hallvord R. M. Steen a écrit :

>>> In many of the scenarios I have working for, the content to be put on the clipboard would come from a "luxury" knowledge structure on the server, one that has access to some semantic source and can infer useful representations out of it; these get put to the clipboard.
>>> An offline HTML would also be an example of it.
>> but I am realizing that this is probably not possible to do because the only way to do obtain something from the server is to wait until a callback is called (and this is good so) at which time the copy event might be long gone already.
> Indeed.
>> Would it be thinkable to *lock* the copy event until either a timeout occurs or an unlock is called?
> It sounds like a quite "advanced" use case. I briefly considered something like event.clipboardData.pushContentsOfURL('/foo/bar') but that would be way to limited in options - POST/GET, post data etc. I would like to defer this to later and see if we get more demand for it. Overall, the push for web applications is a lot about removing logic from the server and adding more on the client's side, so I'm unsure how common this state (when the server knows significantly more than the client-side logic about what should be placed on the clipboard) is and will be going forward.
Received on Tuesday, 17 May 2011 06:51:43 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:32 UTC