[RFC][Icedtea-web]: Changed how cache works.

[Denis Lila]

> Ok to push after removing the checks for compression?

I'm ok with it.

But I will say that I am still uncomfortable with the entries
of recently_used being (timeMillis, path) instead of the other
way around.
Also, is it true that every cached file is in it's own numbered
directory (i.e. each directory <num> contains exactly one cached
file)?
makeNewCacheFile only creates a cache file for the given URL
if the directory <num> does not exist. In other words, if
the cache is empty, and I use an app that caches file1.jar and
file2.jar, doing "ls ~/.icedtea/cache" will give

0 1 recently_used

and the only file in directory "0" is file1.jar, and the only
file in directory "1" is file2.jar.
This seems kind of... redundant to me.

Anyway, the above are not correctness problems, and if desired
we can fix them later. I think this patch should go in.

Regards,
Denis.

----- Original Message -----
> ----- Original Message -----
> > From: "Omair Majid" <omajid at redhat.com>
> > To: "Andrew Su" <asu at redhat.com>
> > Cc: "Denis Lila" <dlila at redhat.com>, "IcedTea"
> > <distro-pkg-dev at openjdk.java.net>
> > Sent: Monday, April 18, 2011 3:23:43 PM
> > Subject: Re: [RFC][Icedtea-web]: Changed how cache works.
> > On 04/18/2011 03:06 PM, Andrew Su wrote:
> > >>
> > >> Are the markCompressed/isCompressed methods used anywhere? If
> > >> not,
> > >> could you please make that a separate patch?
> > >
> > > Yes, I've added the use of isCompressed in CacheEntry.isCached().
> > > Reason being that if the item was extracted, the content-length
> > > reported
> > > by the connection would differ from actual file size, thus forcing
> > > it to
> > > download without actually checking the modified time.
> > >
> >
> > That is a problem, but it seems orthogonal to the rest of the patch.
> > I
> > am not sure simply ignoring the content-length for compressed files
> > is
> > the best thing to do. We wont be able to detect changes in file
> > size.
> > Perhaps we should be storing uncompressed size instead?
> 
> We can discuss a more on this after this gets in.
> 
> >
> > >
> > > Is the patch okay now?
> > >
> >
> > I would have preferred it if the isCompressed() and related stuff
> > were
> > in a separate patch - the rest of the stuff looks ok to me.
> 

> 
> Cheers,
> Andrew