To that end. Could the actual flags be fully documented in a "TO-DO" file
explaining what each one does. If this is applicable to file level only
then it's easily extended to xroot protocol. At the moment no one (other
than JT) is asking for this kind of functionality and when it is asked
it's in the context of HTTP. I also agree that we don't want to start
changing everthing to provide 100% consistency in terms of cache control.
From what I understand, these flags are considered "best effort" and might
be ignored if they cannot be fullfilled even in the HTTP world world.

In the end, it all winds up being a compromise.

On Tue, 14 Mar 2023, Brian P Bockelman wrote:

>> Or you were only thinking of using http?
>
> I would like the feature to be generally useful for any protocol. However, since the driver is better HTTP 1.1 compliance, unless there's a need to push the functionality all the way through to the reads themselves, it seems simpler to leave it as a file-level property. I can see some downsides around code complexity in the read path.
>
> --
> Reply to this email directly or view it on GitHub:
> https://github.com/xrootd/xrootd/pull/1954#issuecomment-1468020991
> You are receiving this because your review was requested.
>
> Message ID: ***@***.***>

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.

[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/xrootd/xrootd/pull/1954#issuecomment-1468255847", "url": "https://github.com/xrootd/xrootd/pull/1954#issuecomment-1468255847", "name": "View Pull Request" }, "description": "View this Pull Request on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

Use REPLY-ALL to reply to list

To unsubscribe from the XROOTD-DEV list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1