- From: Karl Dubost <karld@opera.com>
- Date: Fri, 28 Oct 2011 14:22:26 -0400
- To: Jonathan Mayer <jmayer@stanford.edu>
- Cc: "public-tracking@w3.org Group WG" <public-tracking@w3.org>
Jonathan, Le 26 oct. 2011 à 03:13, Jonathan Mayer a écrit : > 1) The third party notifies the first party through inter-frame communication (e.g. postMessage or fragment identifiers). Do you have an example of what you mean by fragment identifier. These have already a semantic and properties and I wonder how you would use them practically. > 2) The third party notifies the first party through backend communication. For example, the the first and third parties share a unique session identifier, and the first party makes a RESTful call to the third party. You might mean an HTTP request here. RESTful has also a precise meaning that I have rarely seen in deployed APIs. > Drawbacks: > -The first and third parties have to establish a shared identifier, add support for a backend protocol, and do realtime backend data sharing what do you mean by realtime? 1, A client makes an HTTP request with a URI 2. A server might answer with a representation <A> for this URI. 3. This representation <A> might contain link to other resources. The client might choose to request them. 4. The client prioritizes the requests according to certain rules. One point of the Web architecture is that if I do a request on domain1 and domain2, they are not aware of each other. Sharing identifiers seem a bad idea for separation of concerns and for the users. I usually prefer solutions where the user decide what is acceptable for him, and not having the parties negotiating what is good for users. -- Karl Dubost - http://dev.opera.com/ Developer Relations & Tools, Opera Software
Received on Friday, 28 October 2011 18:23:03 UTC