Print

Print


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 or view it on GitHub:
https://github.com/xrootd/xrootd/pull/1954#issuecomment-1468255847
You are receiving this because you are subscribed to this thread.

Message ID: <[log in to unmask]>

########################################################################
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