[
https://issues.apache.org/jira/browse/TUSCANY-2516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12624448#action_12624448
]
Dan Becker commented on TUSCANY-2516:
-------------------------------------
The Atom Binding ETags/LastModified caching provided in TUSCANY-2477 and
demonstrated in TUSCANY-2537 takes advantage of the specific nature of the
Abdera data model. In other words, Feeds and Entries, which both have unique
IDs and updated fields,are used to provide the ETag and the LastModified field
of the HTTP header. There is no need for a user to provide any implementation
since the user already provides Feeds and Entries.
This JIRA is somewhat different. The HTTP binding can transport an arbitrary
data type which may or may not have a unique ID or updated field. A good
example of this is the existing TestGetImpl.java and TestServiceImpl.java in
the Tuscany binding-http-runtime. These are implmentations that read and write
strings to sockets directly. They implement no interface. The only business
data is a raw String.
Because of the lack of a unique ID or update field or specific data type, I am
considering pushing this provision responsibility to the service or API
implementer. How to do this? There seem to be several ways, so let me state
what I have considered to see if it is inline with the requester's expectations.
1) (My preferred design) One way to provide caching information
(ETags/Lastmodified) is to annotate the business APIs that would use them. I
envision a @HTTPRequestCache and @HTTPResponseCache annotation that mark
methods that either provide or expect ETags and LastModified items in the
header. The implementor would receive/provide a data object (perhaps
CacheContext) in which to provide or read ETags/LastModified/predicates in the
method. The implementator could generate these values from data base access,
data values, or any other implementation. The HTTP binding can then inspect
headers of these specially marked methods and take the normal caching actions
as provided in the HTTP spec without ever invoking the implementation. This has
the advantage of allowing complex business interfaces to only cache on a subset
of actions (such as a Collection interface with CRUD methods to only cache on
request methods).
2) Another design would be to require service implementors to implement a
special Cacheable interface (similar to the Serializable interface). The HTTP
binding would then use this information to read or provide ETags/LastModified
in the headers. However, this would add caching overhead to all methods of a
business interface.
Other ideas? Please let me know. I just wanted to propose the path that I am
heading down in this very useful and far reaching feature.
> HTTP binding should support etag and if-modified headers
> --------------------------------------------------------
>
> Key: TUSCANY-2516
> URL: https://issues.apache.org/jira/browse/TUSCANY-2516
> Project: Tuscany
> Issue Type: Wish
> Components: Java SCA Misc Binding Extensions
> Reporter: Jean-Sebastien Delfino
> Assignee: Dan Becker
> Fix For: Java-SCA-Next
>
>
> The HTTP binding currently does not support etag and if-modified headers for
> implementation-resource and implementation-widget components, preventing Web
> browsers to do any caching.
> Supporting etag and if-modified should be easy for the above component
> implementation types, just a matter of calculating a checksum and use it as
> etag or checking the timestamp of the served file.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
