I've filed this as issue 3296. :-) :D
On Mon, Nov 2, 2009 at 2:30 PM, David Anderson <[email protected]> wrote: > > 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]<google-code-hosting%[email protected]> > For more options, visit this group at > http://groups.google.com/group/google-code-hosting?hl=en > -~----------~----~----~----~------~----~------~--~--- > > -- ---------------------------------------------------------------------- :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=.
