On Mon, Nov 2, 2009 at 15:20, Darren Pearce <[email protected]> wrote:
>> Downloads are, by and large, meant to be immutable. It is good to have
>> a stable URL for software releases. With this use case in mind, we
>> serve files with HTTP caching headers set to cache the download, so as
>> to play nicely with caching proxies along the way. This has the
>> unfortunate side-effect that when you change the content, the old
>> content is likely to be served by caching proxies for a while after
>> the change.
>>
>> Yes, this is suboptimal given that we allow download deletion, which
>> opens the door to the practice of changing the content of a download
>> URL (which we discourage for non-technical reasons, release files
>> should be immutable). We are aware of this and are looking into ways
>> of making this suck less while still being HTTP cache friendly.
>
> Thanks for this detailed response, Dave. How about creating a secondary area
> that is similar to the downloads except that it serves the files with the
> No-Cache directive?

That might work, but we don't really want to send the message that "We
now have a web drive area where you can upload and share random
files!" We have enough problems with people treating us as a generic
file host as it is, and adding such a an area would only encourage
that perception (and in turn increase the time we need to spend
banning abusers and dealing with the fallout from that). If anything,
we want to find a way to eliminate that perception while at the same
time offering legitimate open source developers the tools they need,
which is a hard problem :-).

> Probably better than this is to allow project participants to specify
> whether a download should be cached or not. A simple checkbox would suffice.
> It could default to true to represent the 'by and large' immutability of
> downloads and, if switched off, a red warning can advise what this means
> with an appropriate pointer to help pages for more details.
> This way, projects who want to use Java Web Start can do so without worrying
> about caching issues. A by-product of having this boolean indication of
> whether the download is cached/supposedly immutable or not is that the
> 'delete warning page' could be omitted. In fact even better, if a
> 'non-cached' file is re-uploaded, it could automatically overwrite the
> existing file. Perhaps this is too extreme. A simple prompt though to
> confirm would be nice. Hope this all makes sense.

It does indeed. Although again there are various debates (technical,
UX, philosophical, etc.) to be had on what the best solution is, this
is certainly worth considering.

I don't believe we have an issue open for download caching issues,
would you mind filing one on http://code.google.com/p/support ? That
way these ideas will make their way into our bug tracker, where they
can't slip off the radar while we decide what to do :-).

Thanks,
- Dave

> :Darren.
> --
> ----------------------------------------------------------------------
>  :Darren :Pearce
> ----------------------------------------------------------------------
>  *** Shop & Donate: http://buy.at/campuskids ***
> ----------------------------------------------------------------------
>  [email protected]
>  Postdoctoral Researcher
>  London Knowledge Lab, University of London
> ----------------------------------------------------------------------
>  [email protected]
>  Visiting Research Fellow
>  Informatics, University of Sussex
>  http://www.informatics.sussex.ac.uk/users/darrenp/
> ----------------------------------------------------------------------
>  [email protected]
>  http://www.linkedin.com/in/darrenpearce
> ----------------------------------------------------------------------
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Hosting at Google Code" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/google-code-hosting?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to