Closed
Bug 72519
Opened 24 years ago
Closed 9 years ago
support for cacheTokens must be implemented
Categories
(Core :: Networking: Cache, defect)
Core
Networking: Cache
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: gordon, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: arch, Whiteboard: [cache])
This bug is really for clients of cache clients.
A cacheToken is simply an nsISupports with an nsICacheEntryDescriptor wrapped
inside. It may even be an nsICacheEntryDescriptor that is handed out as an
nsISupports.
As long as the cacheToken is held, the underlying cache entry will not be
evicted, and can be "reopened" using the token, even if the entry has been doomed
(and therefore not discoverable by the normal key search).
This mechanism should be used to implement printing, save as, and view source.
URL: http://http://
Keywords: arch
Darin, I'm giving this to you so you can close it when you've implemented
GetCacheToken() in http.
Assignee: gordon → darin
Status: ASSIGNED → NEW
Comment 2•24 years ago
|
||
GetCacheToken() is implemented, but SetCacheToken() is not. We currently do
not have any consumers of this, so I'm pushing back the milestone to Future.
Target Milestone: mozilla0.9 → Future
Shouldn't printing be WYSIWYG and therefor use the current DOM rather then the
original file? The two dosn't neccesarily produce the same result on for
example dynamic pages and form elements.
Comment 4•23 years ago
|
||
What's the status on this? I believe view-source is now using an interface
which is supposed to do the same thing. (see bug 408767) Meanwhile, save-as is
using a completely different workaround. So I think you have consumers.
Could somebody with a deep understanding of the cache see if view-source is
doing the 'right thing', and if not, how hard it will be to make it do so?
Comment 6•23 years ago
|
||
Don't also forget the "Send Page" (where it is especially embarassing if it
turns out you've sent something quite different from what you though you were
sending).
Comment 7•23 years ago
|
||
nope, view-source, etc. do not currently depend on cache tokens. they use soft
references to cache entries, which allow the cache to free old entries in order
to make room for more recently visited content. a cache token could be used to
hold a hard reference to a cache entry, causing it to never go away.
view-source, etc. may one day make use of cache tokens, but for the moment, it
is not part of the design. with a default disk cache size of 50 megabytes, we
think this design should be sufficient 99% of the time. if you feel otherwise,
and would like to discuss the design of view-source, etc. then please take the
discussion to a news group, thx!
Comment 8•23 years ago
|
||
They don't currently depend on cache tokens *because* cache tokens aren't
implemented! What, you want the consumers to break the build before you
consider this useful?
I'm going to try to fix this bug, but I need a hint: what file is GetCacheToken
defined in?
Comment 9•23 years ago
|
||
of course this bug blocks using cache tokens for view-source, etc. but there
currently isn't any plan AFAIK to implement view-source, etc. using cache tokens.
[GS]etCacheToken for HTTP content are implemented in nsHttpChannel.cpp
Comment 10•23 years ago
|
||
Clearly you never read the enormous discussion in bug #40867. The consensus
reached way-back-when seemed to be that cache tokens should be used for view-source.
However, there's a deeper problem than this bug, in that the cache doesn't
really allow proper implementation of cache tokens right now, since cache
entries can be 'overwritten' rather than being replaced. *sigh*
Comment 11•23 years ago
|
||
i'm well aware of the fact that there is a proposed solution to implement
view-source using cache tokens (in fact it was one of the design reasons behind
exposing cache tokens on nsICachingChannel), but AFAIK there is no consensus
that this proposal is the right thing for mozilla, especially not amongst the
maintainers of the relevant code modules.
if we decide that cache entries need to be pinned in the cache for the purposes
of view-source, etc. then we'll need to fix this bug. the work required to fix
this bug is very small, but until we're ready for it, i'd rather we focus our
efforts on the vast number of much more critical bugs ;-)
Comment 12•21 years ago
|
||
What about implementing IE's 'Offline Web pages' using this technology?
Permanently pinning all files in the cache which belong to a selected bookmark?
Should be easy.
Currently, I think there is no way to ensure specific pages are always kept in
the case - therefore I can't rely on pages shown in the History to be accessible
any time.
Comment 13•18 years ago
|
||
-> default owner
Assignee: darin → nobody
QA Contact: gordon → networking.cache
Target Milestone: Future → ---
Comment 14•18 years ago
|
||
*** Bug 262350 has been marked as a duplicate of this bug. ***
Comment 15•18 years ago
|
||
bug 262350 has a partial patch
Comment 16•16 years ago
|
||
Darin Fisher: "if we decide that cache entries need to be pinned in the cache for the purposes of view-source, etc. then we'll need to fix this bug. the work required to fix this bug is very small, but until we're ready for it, i'd rather we focus our efforts on the vast number of much more critical bugs ;-)"
Not pinning the currently open files is highly critical: It prevents people from printing or saving receipts from online credit card purchases; It prevents people on dial-up from saving images and other files that they spent hours downloading; It prevents web developers from viewing the actual source of the page they are looking at while they debug their dynamic web sites; many other harmful data loss issues.
Pinning all open pages (and preventing them being overwritten by any other loading of the same URL in a different tab/window) should be the default behaviour.
Comment 17•16 years ago
|
||
Bug 288462 provides the full summary of all related issues, complete with RFC violations. Should be linked to this one.
Updated•12 years ago
|
Assignee: cbiesinger → nobody
Updated•9 years ago
|
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•