1) How do you interact with the cached files, i.e. what doesn't work
in 9.5+ that does work for you in 9.27-? For instance, do you archive
all image files from the cache or use a text editor with the cached
files that relies on file extensions for syntax highlighting?
2) Could enhancements to opera:cache work-around not having file
extensions on cached files? If so, what enhancements? For instance,
if the MIME type or file extension were listed in opera:cache, would
that be a satisfactory solution?
3) How are you working around the removal of cache files, i.e. are you
using 9.5+ with a different work flow from 9.27?
Thank you for taking the time to answer these questions.
--
Tim Altman
Desktop QA
Opera Software
Remove NO SPAM from e-mail address to reply
> At the risk of opening a can of worms, I'd like to ask some
> questions to those that require cached files to have file
> extensions. One of our developers is evaluating Opera's
> cache back-end and is interested in the use cases for file
> extensions, so they can possibly be taken into account in
> future cache back-end designs. So, if you interact
> directly with Opera's cache via the file system and/or have
> had problems due to the removal of file extensions from
> cached files in 9.5+, please answer the following
> questions:
>
> 1) How do you interact with the cached files, i.e. what
> doesn't work in 9.5+ that does work for you in 9.27-? For
> instance, do you archive all image files from the cache or
> use a text editor with the cached files that relies on file
> extensions for syntax highlighting?
Using the old WordPerfect DOS file manager program, which I like
because you can select and unselect individual files with one
keystroke, the keypad * key, I sort the cache files by size in
the left hand window. I select all those greater 8K, more or
less, and copy them to a work directory in the right hand window
of the file manager program.
In the right hand window, I select and delete .js, .css, .htm,
and .swf files. I sort the files by extension and verify that the
remaining files are all image files, .jpg, .gif, and .png.
I then start XnView, and go to the work directory. I let XnView
generate thumbnails for the files in the directory. I have
Xnview set up to display 40 thumbnails at at time. With my
monitor, the thumbnails are large enough to view but small
enough to allow me to view a large number per screen and block
for mass deletes.
I sort the files by extension. Thus puts together many .gif files
that I can quickly select by row and delete in mass.
I sort the thumbnails by size. Sometimes, I find something I
want to keep in the small images, but not often. Usually I can
select rows and rows of small images that I can quickly block
and delete in a mass delete. If necessary I can easily unselect
individual thumbnails from blocked masses with control click.
I look at the remaining thumbnails and delete what I don't want,
deleting them in mass by selecting whole rows where I can.
I may then find dozen or more images I want to keep, usually
having started from around 2,000.
I have thought automating this operation but have never got
around to it. It doesn't take that much time.
2) Could enhancements
> to opera:cache work-around not having file extensions on
> cached files? If so, what enhancements? For instance, if
> the MIME type or file extension were listed in opera:cache,
> would that be a satisfactory solution?
Opera:cache lacks the facilities of a file manager program to
select, block, sort, cut and paste files quickly or the
functions of XnView to go quickly through thumbnails 40 per
screen at a time.
> 3) How are you working around the removal of cache files,
> i.e. are you using 9.5+ with a different work flow from
> 9.27?
>
I continue to use 9.27.
> 1) How do you interact with the cached files
Here are some of the things I've posted previously:
The fact that most text editors rely on file extensions to choose the
syntax highlighting is another problem. When I view source in Opera 9.5,
or click the link to view an external Javascript file from the error
console, it just appears as black plain text.
The editor I use has command line swithes you can use when
opening files, and I'm sure some other programs must have these too.
Obviously for normal use these are impractical because most files are
opened from the GUI, but if Opera is to launch my editor to view files
then could you at least provide a mechanism to associate command switches
to MIME types so that when I view the source of a HTML file, Opera will
run "notapad2.exe /s 1", and when I click on the link to a Javascript file
from the error console, Opera runs "notapad.exe /s 4" etc.
Obviously the switches syntax is specific to the platform and the editor,
so it has to be flexible and configurable. I would see nothing wrong with
hiding all this in opera:config or let users add this information manually
in INI files whilst leaving 'normal' users with the default behaviour of
viewing source in Opera's own viewer or lauching it 'blind' in an external
viewer set up via the GUI.
When coming across broken web pages I like to view and edit the CSS, JS
and HTML files in the cache to work out what the problem is, and this also
results in no syntax highlighting appearing by default.
How about an option in the cache viewer to export the list as a plain text
file with each line containing a tab-delimited list of file name, MIME
type, modified date, original URL, file size, etc. Techies could use these
files with custom scripts to copy/archive the cache files without needing
extensions. My understanding is that the removal of the extensions was
done with the figure of 2GB of data in mind. That would be a very long
list of file names so it would be worth it for the techies who want to do
things with these files.
Also, what about adding file previews to the cache viewer? Opera can
already create thumbnails for web pages, so it could do that for cached
documents when you hover over the links to them in the cache viewer for
more than a second. These thumbnails are usually cached, so in order to
prevent clutter perhaps they should only be cached for an hour. the cache
viewer could also display cached images when you hover over the links to
them, scaled down if needed.
> could you at least provide a mechanism to associate command switches
> to MIME types so that when I view the source of a HTML file, Opera will
> run "notapad2.exe /s 1"
I forgot to copy another post I made where I said that by adding a new
block to opera6.ini which allows the user to specify a program and command
switches to be associated with each MIME type to use when viewing files
(or simply extend the current INI data that records how Opera should
handle each MIME type to incorporat source viewing choices), smart users
could exploit this system to do things like setting up a graphics program
to be the 'source viewer' for image files.
Wouldn't it be nice to be able to load the URL of an image and click view
source to instantly open it in Gimp/Photoshop, or have it as a right-click
option?
Oh, and a flexible system like this means that users could specify (for
example) PS Pad for viewing HTML files, Topstyle for CSS files and XML
Notepad for XML files, if they wanted to.
When I "View Source" my preferred editor is launched pointing to a file
in the cache. Since the files no longer have a ".html" extension, my
editor doesn't know what colouring/syntax scheme to apply. I've managed
to word around this with some fancy regex experssions applied to the
first line, but not all editors are that clever.
> 2) Could enhancements to opera:cache work-around not having file
> extensions on cached files? If so, what enhancements? For instance,
> if the MIME type or file extension were listed in opera:cache, would
> that be a satisfactory solution?
Not really. My editor looks at the file it is editing. Now, if the
filesystem supported extended attributes, such as mimetype, that would
be different. (Ex OS/2 user here).
> 3) How are you working around the removal of cache files, i.e. are you
> using 9.5+ with a different work flow from 9.27?
I'm lucky. I can usually recognise the file types with regular
expressions, but it's prone to error.
--
Steve Swift
http://www.swiftys.org.uk/swifty.html
http://www.ringers.org.uk
> 1) How do you interact with the cached files, i.e. what doesn't work
> in 9.5+ that does work for you in 9.27-? For instance, do you archive
> all image files from the cache or use a text editor with the cached
> files that relies on file extensions for syntax highlighting?
Examining images from cache, and also capturing video streams for
replaying when the embedded video player follows a bandwidth-
destroying policy of redownloading the video if I want to watch
it again or even rewind it a little.
Then there's the matter of viewing source. The syntax highlighting
issue is especially annoying, as is the inability to trigger filetype-
specific settings in the editor.
> 2) Could enhancements to opera:cache work-around not having file
> extensions on cached files? If so, what enhancements? For instance,
> if the MIME type or file extension were listed in opera:cache, would
> that be a satisfactory solution?
I don't think it could work.
An essential point here is that it's not just a matter of being able
to look at files in the cache, but being able to _use_ files in the
cache. Other products need to be able to open those files, and most
products require the files to be presented in the right way. Without
the correct extension for the content-type that can't happen.
There is the possibility of copying files from cache to elsewhere
and giving them the right filenames in the process: an "extract from
cache" facility. There are problems with that. The main problem is
that if you're perusing large numbers of files with the intention
of keeping only the most interesting ones then you're left with
many unwanted files that you have to clean up yourself. The bulk of
the work moves from saving wanted files to removing unwanted ones.
(Opera can't keep track of the copies and remove them itself because
Opera may not be running when the external application terminates.)
Copies are even worse when it comes to viewing source. If I view the
source of a page I don't want to have to delete the source myself when
I'm done, nor do I want Opera to kill my editor off so it can delete
the file if I close Opera before the editor.
On top of that, there's also the issue of wasted space and time.
Creating a copy of a file merely in order to view it is horrifyingly
slow and inefficient. It might be tolerable for one or two files but
certainly isn't for hundreds.
The alternative to copying a file out of the cache when someone wants
to view it is to alter the name in the index and then rename the file
itself in the cache. That solves all the problems associated with
copied files, and it doesn't create a problem for Opera because there
is no problem with correctly indexed files. (The issue was with new
files that are in the cache but not in the index, so as long as the
changed index is written first and there's a simple way to derive the
name of the file from the name in the index both before and after the
file is renamed there is no problem.)
However, this leads to the obvious question: if files can be renamed
on demand, why not do it for all files when the index is flushed to
disk? And that, of course, gives you a cache in which all cached files
have their extensions from the moment they're first indexed.
> 3) How are you working around the removal of cache files, i.e. are you
> using 9.5+ with a different work flow from 9.27?
I'm using 9.62/10467 when I know that I won't need to use the cache,
9.27/8841 when I need to access the cache or view source.
> At the risk of opening a can of worms, I'd like to ask some questions
> to those that require cached files to have file extensions. One of
> our developers is evaluating Opera's cache back-end and is interested
> in the use cases for file extensions, so they can possibly be taken
> into account in future cache back-end designs.
The best design would simply be to put the extensions back. I've heard
all the arguments about why it was necessary to remove them, but to me
they sound like arguments about how the horseless carriage will never
be a reality: I know those argments don't stand up to scrutiny because
I can do what Opera claims can't be done.
--
Matthew Winn
[If replying by mail remove the "r" from "urk"]
> what doesn't work in 9.5+ that does work for you in 9.27-?
Speaking from a Windows-centric perspective:
Using Windows Explorer with cache -- sort by type, copy all of a type,
automatically open any or all in correct programs by just clicking,
(some also by "drag and drop,"
knowing immediately by sight or by type sorting which files to drag),
show all image thumbnails, "view as filmstrip,"
use all "Explorer context menu extensions"
which apply to each particular file type,
including knowing which previously used "Open with" set, etc.
"Windows Picture and Fax Viewer" -- can't proceed to open
all images in turn, skipping all non-images, in the exact
same order as the current sorting sequence of Windows Explorer,
can't do a slide show.
> Could enhancements to opera:cache work-around not having file
> extensions on cached files? If so, what enhancements?
Other than undoing the original doing?
IMO you wouild never be able to put back all the functionality lost
from Windows Explorer and other Windows programs which automatically
use the built-in "Associations" and/or "screen" all files
by the "types" known to Windows,
whose power of full _native_ Windows integration
is completely eviscerated by the excision of file extensions,
and now left to Opera to consider offering very little back,
still the "hard way," when the "easy [and instantaneous] way"
was always there to begin with.
> For instance, if the MIME type or file extension were listed
> in opera:cache, would that be a satisfactory solution?
Go down the list above, and see, for each issue,
how much of the above is accomplished by that --
some not at all, others only with tedious manual effort (including
need to still rename all individual files saved for subsequent use),
figuratively "bombing" Windows integration "back to the stone age."
Much better than spending effort at Opera to do just that little bit
would be using Nir Sofer's freeware "OperaCacheView,"
which is already so far ahead of anything that opera:cache could do,
if only it didn't have the exact same major problem for me
as opera:cache itself, which is:
I have once mentioned (and posted URLs of screen shots showing)
that neither my opera:cache nor old & new independent "Opera cache viewers"
see practically any files at all that are actually in my
correctly located cache folders (9.62 or even 9.27) -- for some reason,
each file "dcache4.url" is seen by Windows as remaining a
constant 20-byte length, with any Opera version, no matter what heap
of up-to the minute recent files actually populates the cache folder,
with a hex viewer showing nothing in "dcache4.url" but the "high water mark"
(last used or next file name), which only hints at the mysterious problem's
possible origin, without really explaining why "dcache4.url"
behaves so peculiarly on my system (XP Pro/SP2, Symantec Corp 9 AV),
apparently making the cache "invisible" to any program
which depends upon reading that ornery file from disk.
I can not even determine whether Opera itself is using all the files
which it caches, although the fact that some site issues are resolved
by clearing the entire cache suggests that it somehow still does;
perhaps "dcache4.url" is itself cached in Opera's RAM,
without being refected the same on disk, perhaps due
to some mechanism which may be at odds with my anti-malware?
It's hard to believe that some others aren't similarly affected,
although I didn't see anyone confirming what I showed.
At any rate, this kills "OperaCacheView" for me,
and I can't see opera:cache ever even coming close
(which wouldn't matter anyway, because even opera:cache
is also drawing a complete "blank" in 9.62 at this very moment,
even though it, running in parallel with this version,
has a cache folder brimming with real files on disk).
> How are you working around the removal of cache files [extensions?],
> i.e. are you using 9.5+ with a different work flow from 9.27?
I am working around 9.5+ by using 9.27 :)
Thanks for asking; hope you can find use for all the answers.
---
P.S. For "video capture" alone, try NirSoft's
"VideoCacheView" and "WebVideoCap,"
which work with current Opera anyway,
but solve none of the other issues:
http://www.nirsoft.net/utils/ -- Windows treasures
(also has "OperaCacheView," updated frequently :)
--
[...]
Lack of 'filename extensions' doesn't seem to be a problem in Linux;
here's a graphical file manager (Thunar) in my Opera cache directory
<http://tinypic.com/view.php?pic=9zq1e0&s=4> which appears to be close to
what you're looking for.
The file types are usually identified by the first few bytes of the file
contents.
--
-- ^^^^^^^^^^
-- Whiskers
-- ~~~~~~~~~~
Hello,
First of all thanks for the question.
I usually copy files of many types from opera cache to other folder of
my PC. for example, Java applets in jar or class files which I would
like to hav to run offline. Also Flash swf animations that I may wnt
to have on my PC offline. Music files (both site background and the
other) are another file type. And newly sometimes other modern types.
I like this feature of opera so much and I even think that it may be
better if opera to save files with real file names instead of oprXXXX
extensions. I got shoked when I knew that Opera 9.5 does not save file
extensions.
Thanks.
> On Nov 14, 7:25 am, Tim Altman <do....@spam.me.invalid> wrote:
>> At the risk of opening a can of worms, I'd like to ask some questions
>> to those that require cached files to have file extensions. One of
I'd just like to add that I see no point in extending opera cache to
add file manager features.
There are many file managers because there is a wide variation in what
people want from a file manager, and I see no point in trying to duplicate
any of that work. Simply putting the extensions back allows those file
managers that rely on the extension, to be used again.
Opera does need to ensure the cached files do get written to the disk
in a timely manner, or provide a method for a user to force that to
happen.
Regards, Dave Hodgins
--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)
>On Fri, 14 Nov 2008 04:25:42 -0000, Tim Altman <do....@spam.me.invalid>
>wrote:
>
>> 1) How do you interact with the cached files
>
>Here are some of the things I've posted previously:
>
>The fact that most text editors rely on file extensions to choose the
>syntax highlighting is another problem.
Right.
[...]
>The editor I use has command line swithes you can use when
>opening files, and I'm sure some other programs must have these too.
The command line switches indicate which type of syntax highlighting
to use?
[...]
>How about an option in the cache viewer to export the list as a plain text
>file with each line containing a tab-delimited list of file name, MIME
>type, modified date, original URL, file size, etc. Techies could use these
>files with custom scripts to copy/archive the cache files without needing
>extensions.
This sounds like a roundabout solution to certain problems. I'd
prefer to solve the problems directly when possible.
[...]
>Also, what about adding file previews to the cache viewer?
Good idea!
>Tim Altman <do....@spam.me.invalid> wrote in
>news:p9uph4tbql9309r7k...@4ax.com:
>
>> At the risk of opening a can of worms, I'd like to ask some
>> questions to those that require cached files to have file
>> extensions
[...]
>> 1) How do you interact with the cached files
[...]
>I sort the cache files by size in
>the left hand window. I select all those greater 8K, more or
>less, and copy them to a work directory in the right hand window
>of the file manager program.
>
>In the right hand window, I select and delete .js, .css, .htm,
>and .swf files. I sort the files by extension and verify that the
>remaining files are all image files, .jpg, .gif, and .png.
[...]
>I look at the remaining thumbnails and delete what I don't want,
>deleting them in mass by selecting whole rows where I can.
OK, so you are searching for specific images you've viewed on Web
pages you've visited. Is there any reason you don't save the images
directly from the Web sites rather than using the cache?
If opera:cache could export all files of certain types (with correct
extensions) to a directory, would that allow you to upgrade
comfortably?
[...]
>Wouldn't it be nice to be able to load the URL of an image and click view
>source to instantly open it in Gimp/Photoshop, or have it as a right-click
>option?
There already is the Open With menu, but this does sound like another
nice enhancement.
>Tim Altman wrote:
>> 1) How do you interact with the cached files, i.e. what doesn't work
>> in 9.5+ that does work for you in 9.27-?
>
>When I "View Source" my preferred editor is launched pointing to a file
>in the cache. Since the files no longer have a ".html" extension, my
>editor doesn't know what colouring/syntax scheme to apply.
OK. So another case of broken syntax highlighting.
>On Thu, 13 Nov 2008 23:25:42 -0500, Tim Altman
><do....@spam.me.invalid> wrote:
>
>> 1) How do you interact with the cached files, i.e. what doesn't work
>> in 9.5+ that does work for you in 9.27-? For instance, do you archive
>> all image files from the cache or use a text editor with the cached
>> files that relies on file extensions for syntax highlighting?
>
>Examining images from cache, and also capturing video streams for
>replaying when the embedded video player follows a bandwidth-
>destroying policy of redownloading the video if I want to watch
>it again or even rewind it a little.
OK. So, you need the ability to sort based on file type and act on
the sorted files.
>Then there's the matter of viewing source. The syntax highlighting
>issue is especially annoying, as is the inability to trigger filetype-
>specific settings in the editor.
*nod* What text editor do you use?
>On Thu, 13 Nov 2008 22:25:42 -0600, Tim Altman asked:
>
>> what doesn't work in 9.5+ that does work for you in 9.27-?
>
>Speaking from a Windows-centric perspective:
>
>Using Windows Explorer with cache -- sort by type, copy all of a type,
>automatically open any or all in correct programs by just clicking,
OK. So, sorting and acting on certain file types.
>> Could enhancements to opera:cache work-around not having file
>> extensions on cached files? If so, what enhancements?
>
>Other than undoing the original doing?
Yes. ;)
>for some reason,
>each file "dcache4.url" is seen by Windows as remaining a
>constant 20-byte length, with any Opera version, no matter what heap
>of up-to the minute recent files actually populates the cache folder,
>with a hex viewer showing nothing in "dcache4.url" but the "high water mark"
It sounds like it's read-only or something. Have you tried deleting
the cache directory (or just the dcache4.url file) and starting over?
Is your cache directory in a non-standard location that Opera may have
problems editing? What are your disk cache settings?
>On Nov 14, 7:25 am, Tim Altman <do....@spam.me.invalid> wrote:
[...]
>> 1) How do you interact with the cached files
[...]
>First of all thanks for the question.
You're welcome.
>I usually copy files of many types from opera cache to other folder of
>my PC. for example, Java applets in jar or class files which I would
>like to hav to run offline. Also Flash swf animations that I may wnt
>to have on my PC offline. Music files (both site background and the
>other) are another file type. And newly sometimes other modern types.
OK, so sorting and acting upon specific file types.
[...]
>> On Nov 14, 7:25 am, Tim Altman <do....@spam.me.invalid> wrote:
>>> At the risk of opening a can of worms, I'd like to ask some questions
>>> to those that require cached files to have file extensions. One of
>
>I'd just like to add that I see no point in extending opera cache to
>add file manager features.
Right. I agree that trying to make opera:cache into a file manager or
extending the built-in source viewer isn't the right solution.
[...]
>Opera does need to ensure the cached files do get written to the disk
>in a timely manner, or provide a method for a user to force that to
>happen.
Is that not happening now?
>At the risk of opening a can of worms, I'd like to ask some questions
>to those that require cached files to have file extensions.
I want to thank everyone that took the time to reply. I will forward
your use cases to the developer working on the cache back-end. I hope
we can find a solution that allows you all to upgrade to and enjoy a
future version of Opera.
Just to summarize, the two main use cases seem to be syntax
highlighting in text editors and sorting by file type and using a
program (Windows Explorer, another file manager, etc.) to manipulate
files of a certain type.
> The command line switches indicate which type of syntax highlighting
> to use?
Yes. If I go to command line and use "Notepad2 /s css C:\dir\opr0004A"
then it will launch the file opr0004A in Notepad2 and force the CSS
highlighting scheme. I presume other editors have similar features? Since
Opera launches the editor when you view the source, it's possible for it
to attach these switches based upon the MIME type.
>> How about an option in the cache viewer to export the list as a plain
>> text file
> This sounds like a roundabout solution to certain problems. I'd
> prefer to solve the problems directly when possible.
I don't see how you can without abandoning whatever you're trying to do
with Opera and restore extensions, but is archiving cache files and other
unusual uses for those files a problem for Opera to deal with?
My idea isn't a solution to those problems, it's a new feature that will
help people achieve what they want to do that really isn't within the
remit of a web browser. If Opera can easily export a list of its cached
files then it's entirely up to the user what they want to do with that
list. If one use for it is to write or download a script (Perl, VBS, or
whatever) that parses this list and copies the cached files to a backup
directory whilst adding extensions then it's up to them. Opera can stay
without extensions and the user can get them back fairly easily if they
have to.
The features's not a million miles away from being able to save a HTML web
page, but when you use a .txt extension Opera strips out all the markup
and converts the document into a plain text file, complete with white
space to centre or right-align text where necessary and 80 dashes wherever
a <hr> should go.
>On Tue, 18 Nov 2008 21:14:45 -0000, Tim Altman <do....@spam.me.invalid>
>wrote:
>
>> The command line switches indicate which type of syntax highlighting
>> to use?
>
>Yes. If I go to command line and use "Notepad2 /s css C:\dir\opr0004A"
>then it will launch the file opr0004A in Notepad2 and force the CSS
>highlighting scheme. I presume other editors have similar features? Since
>Opera launches the editor when you view the source, it's possible for it
>to attach these switches based upon the MIME type.
OK.
>>> How about an option in the cache viewer to export the list as a plain
>>> text file
>
>> This sounds like a roundabout solution to certain problems. I'd
>> prefer to solve the problems directly when possible.
>
>I don't see how you can without abandoning whatever you're trying to do
>with Opera and restore extensions, but is archiving cache files and other
>unusual uses for those files a problem for Opera to deal with?
>
>My idea isn't a solution to those problems, it's a new feature that will
>help people achieve what they want to do that really isn't within the
>remit of a web browser. If Opera can easily export a list of its cached
>files then it's entirely up to the user what they want to do with that
>list. If one use for it is to write or download a script (Perl, VBS, or
>whatever) that parses this list and copies the cached files to a backup
>directory whilst adding extensions then it's up to them. Opera can stay
>without extensions and the user can get them back fairly easily if they
>have to.
Why not just have the functionality to export files of a certain type
to a directory (with correct extensions) directly built into Opera?
>> Opera does need to ensure the cached files do get written to the disk
>> in a timely manner, or provide a method for a user to force that to
>> happen.
>
> Is that not happening now?
Is it possible that a few recent files may only be cached in RAM at the
time the user wants to do something with them?
But, and I'm sure I've seen a couple of other posters mention this,
whenever I view opera:cache in 9.62 it shows none of my cached files. I
know they're cached because I can see them from Explorer in the cache
folder, and Opera doesn't download them again when I re-view a page.
I just viewed opera:cache in 9.62, reloaded a couple of times and this is
all that appears:
Cache Items in Memory
Filename Size Address
opr005P6 96116 http://help.opera.com/servicefiles/userjsfiles/all/browserjs-950-20080701.js
opr004M5 96168 http://help.opera.com/servicefiles/userjsfiles/all/browserjs-950-20080625.js
opr006DR 96577 http://help.opera.com/servicefiles/userjsfiles/all/browserjs-950-20080707.js
I have Opera set to wipe the cache and cookies on exit but from quickly
experimenting, changing those settings doesn't help with the opera:cache
list. I'm not sure which version this starting happening with.
> Why not just have the functionality to export files of a certain type
> to a directory (with correct extensions) directly built into Opera?
Sure, that would be more direct. I have no interest in archiving cached
files myself but would those who do be happy to either export one MIME
type at a time, or all at once including the types they don't want to
archive?
I can see them moaning if they only want HTML, JS and CSS files and have
to either use the export three times or waste time and disk space
needlessly copying all the other temporary files ;-)
> On Mon, 17 Nov 2008 18:22:25 -0500, "David W. Hodgins"
> <dwho...@nomail.afraid.org> wrote:
>
> >Opera does need to ensure the cached files do get written to the disk
> >in a timely manner, or provide a method for a user to force that to
> >happen.
>
> Is that not happening now?
The index isn't. Index writes are deferred, which is why external
cache viewers are unable to find recent files in the cache.
> On Sat, 15 Nov 2008 10:36:21 +0000, Matthew Winn
> <o*@matthewwinn.me.urk> wrote:
>
> >On Thu, 13 Nov 2008 23:25:42 -0500, Tim Altman
> ><do....@spam.me.invalid> wrote:
> >
> >> 1) How do you interact with the cached files, i.e. what doesn't work
> >> in 9.5+ that does work for you in 9.27-? For instance, do you archive
> >> all image files from the cache or use a text editor with the cached
> >> files that relies on file extensions for syntax highlighting?
> >
> >Examining images from cache, and also capturing video streams for
> >replaying when the embedded video player follows a bandwidth-
> >destroying policy of redownloading the video if I want to watch
> >it again or even rewind it a little.
>
> OK. So, you need the ability to sort based on file type and act on
> the sorted files.
Along with the ability to actually see the content of the files in a
suitable viewer.
> >Then there's the matter of viewing source. The syntax highlighting
> >issue is especially annoying, as is the inability to trigger filetype-
> >specific settings in the editor.
>
> *nod* What text editor do you use?
Vim. It _can_ do some content sniffing if set up for it, but setting
it up that way interferes with my use of it as a normal editor. For
example, I don't want it to assume that I'm editing an HTML document
simply because it finds something that resembles a tag.
Content sniffing is also unreliable because many web pages are a
hideous soup of tags that confuse filetype detection. Example: I've
seen some runtime-generated pages that have immense numbers of blank
lines, which defeats content sniffing that examines only the first few
lines of a file for performance reasons.
I fixed this for the "View Source" with a litle wrapper-script as my
external source viewer. Works lika charm, without interfering my normal
settings for vim.
,----
| #!/bin/bash
| gvim -c 'set filetype=html linebreak' $1
`----
Regards
Jens
Same here. I thought it were a Linux problem, cause I placed the cache4
directory in a tmpfs in RAM through a symlink in $HOME/.opera.
Right now my cache is filled with 88M, but nothing appears in
opera:cache.
> I have Opera set to wipe the cache and cookies on exit but from quickly
> experimenting, changing those settings doesn't help with the opera:cache
> list. I'm not sure which version this starting happening with.
I mentioned this since there are no extensions on the cached files.
Before opera:cache worked for several years.
Regards
Jens
> I fixed this for the "View Source" with a litle wrapper-script as my
> external source viewer. Works lika charm, without interfering my normal
> settings for vim.
> ,----
> | #!/bin/bash
> | gvim -c 'set filetype=html linebreak' $1
> `----
But what about viewing JS and CSS files from the error console, or XML
files (including SVG images)? ;-)
1. I don't know then what images I want to save. I decide later.
I long ago learned not to save things because I might want them,
whether a clipping from the news paper or an image on the
internet. You wind up with piles of clippings and megabytes of
images and eventually have to spend time figuring out what to
throw away and what to keep.
2. Clicking and saving every individual image I might want to
keep is a lot of work and time. The way I do it is very time
efficient. Deletes and copying is fast, no dialog box. Going
through as save dialog box is slow.
> If opera:cache could export all files of certain types
> (with correct extensions) to a directory, would that allow
> you to upgrade comfortably?
>
I need the ability to sort by size to avoid copying and having to
going through small 2 and 3 K files that I know I do not want.
That is easy to do with a file manager.
OK.
[...]
>2. Clicking and saving every individual image I might want to
>keep is a lot of work and time. The way I do it is very time
>efficient. Deletes and copying is fast, no dialog box. Going
>through as save dialog box is slow.
Right.
>> If opera:cache could export all files of certain types
>> (with correct extensions) to a directory, would that allow
>> you to upgrade comfortably?
>
>I need the ability to sort by size to avoid copying and having to
>going through small 2 and 3 K files that I know I do not want.
>That is easy to do with a file manager.
OK.
True.
>On Tue, 18 Nov 2008 16:22:24 -0500, Tim Altman
><do....@spam.me.invalid> wrote:
>
>> On Sat, 15 Nov 2008 10:36:21 +0000, Matthew Winn
>> <o*@matthewwinn.me.urk> wrote:
>>
>> >On Thu, 13 Nov 2008 23:25:42 -0500, Tim Altman
>> ><do....@spam.me.invalid> wrote:
>> >
>> >> 1) How do you interact with the cached files, i.e. what doesn't work
>> >> in 9.5+ that does work for you in 9.27-? For instance, do you archive
>> >> all image files from the cache or use a text editor with the cached
>> >> files that relies on file extensions for syntax highlighting?
>> >
>> >Examining images from cache, and also capturing video streams for
>> >replaying when the embedded video player follows a bandwidth-
>> >destroying policy of redownloading the video if I want to watch
>> >it again or even rewind it a little.
>>
>> OK. So, you need the ability to sort based on file type and act on
>> the sorted files.
>
>Along with the ability to actually see the content of the files in a
>suitable viewer.
Right. By "act on", I meant something along the lines of export them
(with file extensions) to a directory for manipulation by another
program.
>> >Then there's the matter of viewing source. The syntax highlighting
>> >issue is especially annoying, as is the inability to trigger filetype-
>> >specific settings in the editor.
>>
>> *nod* What text editor do you use?
>
>Vim. It _can_ do some content sniffing if set up for it, but setting
>it up that way interferes with my use of it as a normal editor.
OK.
>On Tue, 18 Nov 2008 21:33:52 -0000, Tim Altman <do....@spam.me.invalid>
>wrote:
>
>>> Opera does need to ensure the cached files do get written to the disk
>>> in a timely manner, or provide a method for a user to force that to
>>> happen.
>>
>> Is that not happening now?
>
>Is it possible that a few recent files may only be cached in RAM at the
>time the user wants to do something with them?
I don't believe that should happen, but it may depend on your cache
settings.
>But, and I'm sure I've seen a couple of other posters mention this,
>whenever I view opera:cache in 9.62 it shows none of my cached files. I
[...]
>I just viewed opera:cache in 9.62, reloaded a couple of times and this is
>all that appears:
>
>Cache Items in Memory
>Filename Size Address
>opr005P6 96116 http://help.opera.com/servicefiles/userjsfiles/all/browserjs-950-20080701.js
>opr004M5 96168 http://help.opera.com/servicefiles/userjsfiles/all/browserjs-950-20080625.js
>opr006DR 96577 http://help.opera.com/servicefiles/userjsfiles/all/browserjs-950-20080707.js
>
>I have Opera set to wipe the cache and cookies on exit but from quickly
>experimenting, changing those settings doesn't help with the opera:cache
>list. I'm not sure which version this starting happening with.
Yes, we have a bug report about that.
Strg+J, mark the links to images you want to save and download them
at once.
I spoke about "View Source". Since when can you open JS and CSS files
from the error console directly in an external editor?
For everything else -> :filetype=foo ;-)
> I spoke about "View Source". Since when can you open JS and CSS files
> from the error console directly in an external editor?
I might have made a mistake about CSS files, though I'm sure I've done it
before. But certainly Javascript files have been opened by the error
console since it first appeared as the 'Javascript console'. Back then,
the URL of external JS files was presented as a link and if you clicked
it, it'd open in your source viewer. From Opera 9.0, they got rid of the
URL link and gave you an 'edit' icon to the right of the error message to
click instead.
If you are going to want to view source then clearly you are a techie and
have a special interest in such things, so it's reasonable to expect the
problem be fixed for the error console as well as viewing the HTML while
browsing.
And while I'm at it, if I have made a mistake about viewing CSS files, can
Opera please add this to the error console. Why can I open JS files but
not CSS? Surely I'm likely to want to debug both?
This must be a feature in the win-version. I have definitely no 'edit'
button in the error console. There's only 'delete' an 'exit'.
If you have this function you're right that my wrapper doesn't help
much.
> If you are going to want to view source then clearly you are a techie and
> have a special interest in such things, so it's reasonable to expect the
> problem be fixed for the error console as well as viewing the HTML while
> browsing.
If you're vim-using techie you know :filetype
> At the risk of opening a can of worms, I'd like to ask some
> questions to those that require cached files to have file
> extensions. One of our developers is evaluating Opera's
> cache back-end and is interested in the use cases for file
> extensions, so they can possibly be taken into account in
> future cache back-end designs. So, if you interact
> directly with Opera's cache via the file system and/or have
> had problems due to the removal of file extensions from
> cached files in 9.5+, please answer the following
> questions:
>
> 1) How do you interact with the cached files, i.e. what
> doesn't work in 9.5+ that does work for you in 9.27-? For
> instance, do you archive all image files from the cache or
> use a text editor with the cached files that relies on file
> extensions for syntax highlighting?
No one has mentioned the system file indexing function raised in
an earlier post in the group by someone calling themselves self,
who said:
>I tried 9.5 but when I found that its cache did not show the
file extensions I returned to 9.27 where I am, and where I will
stay.
>The file extensions are essential in allowing me to use Copernic
Desktop to keep a running record of everything I have seen on the
web. I have found it invaluable to be able to go back to an
article that I might have seen months ago and which I can only
recall a few key words of.
http://groups.google.com/group/opera.general/browse_thread/thread
/c217bf0f5ea36079/75f538a34c637673?lnk=gst&q=copernic#75f538a34c6
37673
The Vista file search facility has made indexed file searching a
standard function.
Opera too has file search facility, but as I understand it, it
works only for Opera, not other documents on your system.
The poster described his use of Copernic.
For lack of a present need, I haven't used any of these programs.
Having to have one file search facility, like the Vista program
or Copernic to search word processing documents and another one
for cache, like the Opera facility, makes no sense. This is
unnecessary redundacy. A user should be able to use one indexing
and searching system to search all file types on his system.
Yet, as the poster described, removing the file extensions means
a user would have to figure out manually the file type when the
search results included a file in Opera cache.
I think the poster using Copernic for one system wide search
program not tied to any other system component has the right idea
for how to do search indexing.
It seems to me that, in the long run, Opera has no choice but to
interface with non-Opera indexing and search programs and make
available to them file types and extensions.
2) Could enhancements
> to opera:cache work-around not having file extensions on
> cached files? If so, what enhancements? For instance, if
> the MIME type or file extension were listed in opera:cache,
> would that be a satisfactory solution?
> 3) How are you working around the removal of cache files,
> i.e. are you using 9.5+ with a different work flow from
> 9.27?
>
> Thank you for taking the time to answer these questions.
>
On Tue, 18 Nov 2008 22:36:10 +0100, Tim Altman <do....@spam.me.invalid>
wrote:
> On Thu, 13 Nov 2008 23:25:42 -0500, Tim Altman
> <do....@spam.me.invalid> wrote:
>
>> At the risk of opening a can of worms, I'd like to ask some questions
>> to those that require cached files to have file extensions.
>
> I want to thank everyone that took the time to reply. I will forward
> your use cases to the developer working on the cache back-end. I hope
> we can find a solution that allows you all to upgrade to and enjoy a
> future version of Opera.
>
> Just to summarize, the two main use cases seem to be syntax
> highlighting in text editors and sorting by file type and using a
> program (Windows Explorer, another file manager, etc.) to manipulate
> files of a certain type.
>
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
JHM:
>> for some reason,
>> each file "dcache4.url" is seen by Windows as remaining a
>> constant 20-byte length, with any Opera version, no matter what heap
>> of up-to the minute recent files actually populates the cache folder,
>> with a hex viewer showing nothing in "dcache4.url" but the "high water mark"
TA:
> It sounds like it's read-only or something. Have you tried deleting
> the cache directory (or just the dcache4.url file) and starting over?
I just did
(deleted "cache4" directory at path given below, then opened 9.62,
which is installed in its own separate program files path);
this re-created "cache4" directory (at same path given below),
and made no difference to results.
In particular, after visiting http://news.google.com/
(containing many images), opeing opera:cache displays NO objects.
> Is your cache directory in a non-standard location
> that Opera may have problems editing?
On WinXP Pro SP2 (with user being member of computer "Administrators" group):
"C:\Documents and Settings\jhmeyers\Local Settings\Application Data\Opera\Opera95\profile\cache4"
When all files are sorted by modification time,
file dcache4.url is often somewhere in the middle of the entire file list
(so it is not quite up to date, yet many cache files
are older than its last modification time)
After some settling down, dcache4.url may become the most recently modified file,
yet opera:cache still displays an empty list:
"Cached Items" title, column headings, one empty line (or spacer).
dcache4.url "properties," as always, declares its length to be 20 bytes,
and its content, when displayed in a hex editor (also listing just 20 bytes),
shows the "high water mark" cache file suffix in the last few bytes.
> What are your disk cache settings?
Memory cache: Automatic
Disk Cache: 20MB
[x] Empty on exit
Check documents: Always
Check images: Every 5 hours
--
> * Eik <sp...@hotmail.com> [19-11-08 18:44]:
> > If you are going to want to view source then clearly you are a techie and
> > have a special interest in such things, so it's reasonable to expect the
> > problem be fixed for the error console as well as viewing the HTML while
> > browsing.
>
> If you're vim-using techie you know :filetype
Whether you're a techie or not, it's unacceptable to have to enter by
hand information that is already known to the calling software.
> OK. So, sorting and acting on certain file types.
In originally explaining why Opera started omitting file type suffixes
from cache files, contradictory rationalizations were given;
an Opera developer said one thing in a blog,
another person said something else ("security") in this forum.
Windows' built-in Explorer integration
and the native workings of numerous other Windows applications,
based on existing suffixes, already offer huge advantages,
and are already about as perfect as any substitute could ever hope to be.
Adjustments to Opera are unlikely ever to be able
to replace or duplicate the advantages of letting Windows
do what it already does best.
Might I ask, given the time you have all had to get together
and find out more about why Opera did this thing,
whether you would like to review and explain
what the actual motivation and values of the original action are,
and how effectively you think they have been accomplished?
What are the use cases behind it, for example,
to compare with all those presented by its participating users here?
Thank you.
--
Muahahaha. Sorry, but dumb explorer insisting on opening files only
based on changeable suffixes is as far from perfect as it could be.
There are other concepts to look on what type of file something is
that you can't manipulate so easy as the one in windows.
>On Tue, 18 Nov 2008 15:28:05 -0600, Tim Altman wrote:
>
>JHM:
>>> for some reason,
>>> each file "dcache4.url" is seen by Windows as remaining a
>>> constant 20-byte length, with any Opera version, no matter what heap
>>> of up-to the minute recent files actually populates the cache folder,
>>> with a hex viewer showing nothing in "dcache4.url" but the "high water mark"
[...]
>> What are your disk cache settings?
>
>Memory cache: Automatic
>Disk Cache: 20MB
>[x] Empty on exit
I believe "Empty on exit" is the culprit.
>On Tue, 18 Nov 2008 15:28:05 -0600, Tim Altman wrote:
>
>> OK. So, sorting and acting on certain file types.
>
>In originally explaining why Opera started omitting file type suffixes
> from cache files, contradictory rationalizations were given;
>an Opera developer said one thing in a blog,
>another person said something else ("security") in this forum.
[...]
>Might I ask, given the time you have all had to get together
>and find out more about why Opera did this thing,
>whether you would like to review and explain
>what the actual motivation and values of the original action are,
>and how effectively you think they have been accomplished?
There was some conflicting information about this change, mostly
because (at least) I thought it was done for reasons of security (so
virus scanners won't find viruses in Opera's cache) while according to
the developer that did the change, it was done for performance
reasons. His explanation is available at
http://my.opera.com/community/forums/topic.dml?id=203663&t=1227279873&page=3#comment2403083.
The performance work Jonny started is not complete in 9.5 (and
probably won't be completed until next year, when the new developer's
work is finished), so it's not possible to measure the effectiveness
of the changes yet.
I'm sure Matthew will be happy to chime in and point out the flaws in
Jonny's work, but that point is moot now as someone else is working on
finishing Jonny's work and I don't even know if Jonny's original
design is being used. The performance improvements released by the
new developer's work are very significant (on the order of 50x faster
in some cases).
>I guess mining for .swf files was also mentioned. Sometimes it is the only
>way to obtain the flash from a website.
Yes, sorting by file type covers that use case.
>Tim Altman <do....@spam.me.invalid> wrote in
>news:p9uph4tbql9309r7k...@4ax.com:
>
>> At the risk of opening a can of worms, I'd like to ask some
>> questions to those that require cached files to have file
>> extensions. One of our developers is evaluating Opera's
>> cache back-end and is interested in the use cases for file
>> extensions, so they can possibly be taken into account in
>> future cache back-end designs. So, if you interact
>> directly with Opera's cache via the file system and/or have
>> had problems due to the removal of file extensions from
>> cached files in 9.5+, please answer the following
>> questions:
>>
>> 1) How do you interact with the cached files, i.e. what
>> doesn't work in 9.5+ that does work for you in 9.27-? For
>> instance, do you archive all image files from the cache or
>> use a text editor with the cached files that relies on file
>> extensions for syntax highlighting?
>
>No one has mentioned the system file indexing function raised in
>an earlier post in the group by someone calling themselves self,
>who said:
[...]
>It seems to me that, in the long run, Opera has no choice but to
>interface with non-Opera indexing and search programs and make
>available to them file types and extensions.
That of course depends on the way the search program indexing works,
i.e. if it requires file extensions. OS X's indexer, Spotlight,
includes support for plug-ins, which, in theory, someone could make
for Opera's cache.
JHM:
>> Windows' built-in Explorer integration
>> and the native workings of numerous other Windows applications,
>> based on existing suffixes, already offer huge advantages,
>> and are already about as perfect as any substitute could ever hope to be.
JS:
> Sorry, but dumb explorer insisting on opening files only
> based on changeable suffixes is as far from perfect as it could be.
> There are other concepts to look on what type of file something is
> that you can't manipulate so easy as the one in windows.
If you are using the Windows OS, then Windows Explorer works perfectly for you
(including allowing you to "drag and drop" or "Open with" or "Send to"
any alternate applications of your own choosing, plus other choices
which automatically appear for various file types, which can even be provided
by any general "file type analyzer" that anyone might choose to add on),
while opera:cache doesn't work at all (per my other post),
and would be nearly useless even if it did work.
Matthew Winn [writing elsewhere about detached windows]:
> It's like the cache extensions all over again. You take a wonderful
> feature used by many people, completely ruin it, and then try to bodge
> together a compromise that makes it slightly less ruined.
It's the vendor's call, but it keeps looking as if
existing features could have been preserved as options,
and some new features (e.g. autosave) made optional
(even if the default upon installation),
but flexibility and choice seems to be fading away.
--
>>> What are your disk cache settings?
>> Memory cache: Automatic
>> Disk Cache: 20MB
>> [x] Empty on exit
> I believe "Empty on exit" is the culprit.
You're right! -- un-checking it in 9.62 (or 9.27)
does start causing "dcache4.url" to record file data
(the "high water mark" file name stays at the end of the file),
and allows NirSoft's "OperaCacheView" to work
(which is vastly more useful than opera:cache)
However, it of course eliminates emptying the cache automatically
upon closing Opera, which is its purpose -- is it thus a bug,
common to both 9.27 and 9.5+ ??? (after all, until Opera is closed,
why should that option have any other effect?)
It also seems most peculiar that opera:cache depends upon
the same file, which contains no entries while running,
if I ask that cache be purged only _after_ running.
After all, how does Opera manage to make use of its own cache
while running, if it can't, also while running,
list what it should always know to be in the cache?
Here is the "Help" on cache options for 9.62:
http://help.opera.com/Windows/9.62/en/history.html
Anything about "Empty on exit" disabling "opera:cache"?
(I've also tried to "search Opera" for things like
"opera:cache" and "address bar,"
but get "nothing found" every time)
So, to work around what appears to be a bug,
I can disable "Empty on exit" and manually clear cache before exiting;
is that the situation as it stands now?
Thanks for identifying, at last, what's been going on for ages,
as earlier reported with no one commenting at all.
--
> Yet, as the poster described, removing the file extensions means
> a user would have to figure out manually the file type when the
> search results included a file in Opera cache.
> I think the poster using Copernic for one system wide search
> program not tied to any other system component has the right idea
> for how to do search indexing.
> It seems to me that, in the long run, Opera has no choice but to
> interface with non-Opera indexing and search programs and make
> available to them file types and extensions.
This reminds me that there is another impact of not having extensions,
for Windows:
Searching for "files containing [text string]" depends upon the file
extensions to decide whether or not to scan each file!
Reference:
http://www.mostlycreativeworkshop.com/article59.html
One might say that in looking to assuage one single problem at a time,
generally in a most inferior manner, one fails to see the big picture,
which is that there is a complete and effective design, already integrating
and facilitating numerous parts of the operating system environment,
all of which are crippled by disabling one design element at its core,
like ripping out the spinal column and then trying to add
one specialized prosthetic at a time, each one inferior
to the native, natural, original limb which had already existed,
all of which had originally coordinated perfectly with each other,
needing no external prostheses at all.
--
> Thanks for identifying, at last, what's been going on for ages,
> as earlier reported with no one commenting at all.
That explains why I wasn't able to recreate the problem. I have a clear cache
button, that I use, instead of having opera clear the cache on exit. I
generally prefer to control how and when things get deleted.
Regards, Dave Hodgins
--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)
> I just viewed opera:cache in 9.62, reloaded a couple of times
> and this is all that appears:
>
> Cache Items in Memory
> [...]
So "[x] Empty on exit" seems to leave file "dcache4.url"
with no record of files in disk cache,
and even Opera itself is then able to display only its memory-cached items
(which are inaccessible to any other program anyway).
> I have Opera set to wipe the cache and cookies on exit
> but from quickly experimenting, changing those settings
> doesn't help with the opera:cache list.
It seems to take some while (after un-checking the "Empty" option)
for new cached files to start appearing in the index
(restarting after deleting cache folder ought to force the matter :)
so perhaps that's why you didn't see immediate relief.
> I'm not sure which version this starting happening with.
It seems to have been the same in 9.27,
so perhaps has been a fact throughout an entire series,
continuing into 9.5+
--
I agree. For me this is a bug. I want the cache to be deleted *after*
closing opera, but as long as it runs I'll be able to look in this
cache. I can't see any reason for this behaviour, since it works in the
older versions, and 'clear cache after closing' is my default setting for
years.
> Muahahaha. Sorry, but dumb explorer insisting on opening files only
> based on changeable suffixes is as far from perfect as it could be.
> There are other concepts to look on what type of file something is
> that you can't manipulate so easy as the one in windows.
Binary files can have magic numbers in them that make identification
of the content fairly easy, but for various types of text files that's
not possible. In the past I've had no end of trouble with files being
misidentified. (Most annoying was a product from a company whose name
begins with "M"[1], which identified as XML any text that included the
string <?xml at any point and then refused to handle the file because
it turned out not to be well-formed XML.)
In order to correctly identify text files you need some sort of
out-of-band indication of the file type, and although it's a very
1960s idea a file extension does the job reasonably well.
[1] and ends in "icrosoft".
>On Fri, 21 Nov 2008 09:00:50 -0600, Tim Altman wrote:
>
>>>> What are your disk cache settings?
>
>>> Memory cache: Automatic
>>> Disk Cache: 20MB
>>> [x] Empty on exit
>
>> I believe "Empty on exit" is the culprit.
>
>You're right!
[...]
>is it thus a bug,
>common to both 9.27 and 9.5+ ???
Yes, it's a bug. We have a bug report.
[...]
>So, to work around what appears to be a bug,
>I can disable "Empty on exit" and manually clear cache before exiting;
>is that the situation as it stands now?
Yes, that should work.
For me another point to argument for making the bugreports redable to
the users. No one knows wether there is a report on such issues, if a
developer had noticed these things or not.
For all my other software I can take a look at the Debian bugreports if
anyone has a similar problem or if not then I report the bug. In Opera I
have no overview about these things and so I decide not to report a bug
by myself. Thats a little bit annoying.
> I guess mining for .swf files was also mentioned. Sometimes it is the only
> way to obtain the flash from a website.
There are actually applications that can look for specific file types
on pages you visit and allow you to download them relatively easily,
such as Orbit Downloader:
http://www.orbitdownloader.com/
This depends on which operating system you are using, of course.
You may find that these applications can sometimes be more convenient
to use than manually looking around in the browser cache.
--
Håvard Kvam Moen, QA SaD, Opera Software
I was mainly using this cache mining when I could not discover the URL for
the file directly from the source of the page.
Maybe your solution can help, I'll check it out. Thanks for the tip.
> I'm sure Matthew will be happy to chime in and point out the flaws in
> Jonny's work, but that point is moot now as someone else is working on
> finishing Jonny's work and I don't even know if Jonny's original
> design is being used. The performance improvements
> released by the new developer's work are very significant
> (on the order of 50x faster in some cases).
Faster than what, during performance of what task(s),
actually accomplished by doing what,
and under what conditions?
Will all web sites now display in virtually zero time?
(that's the very least I would expect from a "50x faster" overall product :)
My own computer can't have that much to gain, because it isn't slow at anything,
so a million-fold gain in anything at all would have less practical significance,
like a 100% savings on something costing a penny a week.
One of the original claims was made about a cache that was gigabytes in size
(the number of retained files was not mentioned, that I can remember),
and hardly a soul participating here could even imagine the use
of such a cache, nor could imagine how merely making all file names
the same length could make any huge difference (note that unless
this cache is used in a strictly FIFO manner at all times,
no original set of file names can even remain consecutive,
during any long session or series of sessions,
so rationalizations based on original consecutive naming
somehow seemed a bit weak).
Engineers might actually re-design an automobile body
to be more aerodynamic, offering less wind resistance,
and thereby actually get better gas mileage,
and at the same time paint it green, but that does not necessarily mean
that the accompanying repainting was actually a highly contributory factor
towards whatever actually might have been accomplished,
so perhaps something else has been made more efficient,
not necessarily due to one factor that just happened to come along with it.
Lastly, the circumstances of previously touted gains
were said to be realized mainly after crashes, which brought into question
whether the cost, in terms of greater loss in efficiency in all
non-crash, normal tasks for which many capable users had previously
employed Opera as a once far more useful developer's tool,
once having been farther above others in its class,
was actually any worthwhile trade-off at all, unless, of course,
crashing is to be expected with some non-negligible frequency,
with gigabyte caches being the norm, thus overwhelming other considerations.
> There was some conflicting information about this change,
> mostly because (at least) I thought it was done for reasons of security
> (so virus scanners won't find viruses in Opera's cache) while according
> to the developer that did the change, it was done for performance reasons.
This itself suggests that even senior members of the overall Opera team,
who are most helpful to everyone in this forum, may yet at times have to convey
only second-hand information. When the imagination of other apparently
very experienced software developers not connected with Opera
is strained to fathom those second-hand explanations,
the thought comes that it might still be worthwhile
for the top technical insiders at Opera to take a really close look,
to make sure that whatever is going on
is actually living up to the hype of its press releases,
and not another "The fundamentals of the economy are strong" by John McCain
http://primebuzz.kcstar.com/?q=node/14393
> http://my.opera.com/community/forums/topic.dml?id=203663&t=1227279873&page=3#comment2403083
That seems to be the same original story, to which the above comments still apply.
Thank you very much to you, to Rijk, and others, for doing your best to serve all,
even while a bit "under fire" as the front men for Opera in the forums.
--
In article <p9uph4tbql9309r7k...@4ax.com>,
do....@spam.me.invalid says...
> At the risk of opening a can of worms, I'd like to ask some questions
> to those that require cached files to have file extensions. One of
> our developers is evaluating Opera's cache back-end and is interested
> in the use cases for file extensions, so they can possibly be taken
> into account in future cache back-end designs. So, if you interact
> directly with Opera's cache via the file system and/or have had
> problems due to the removal of file extensions from cached files in
> 9.5+, please answer the following questions:
>
> 1) How do you interact with the cached files, i.e. what doesn't work
> in 9.5+ that does work for you in 9.27-? For instance, do you archive
> all image files from the cache or use a text editor with the cached
> files that relies on file extensions for syntax highlighting?
> 2) Could enhancements to opera:cache work-around not having file
> extensions on cached files? If so, what enhancements? For instance,
> if the MIME type or file extension were listed in opera:cache, would
> that be a satisfactory solution?
> 3) How are you working around the removal of cache files, i.e. are you
> using 9.5+ with a different work flow from 9.27?
>
> Thank you for taking the time to answer these questions.
>
>
--
Pat
> Once a week i transfer all my cache files to an archive folder.
> There I delete all but the html files. I then use Copernic to index
Did you consider the workaround given in
http://groups.google.ca/group/opera.general/msg/90831bfe868eb655?
>On Fri, 21 Nov 2008 09:12:07 -0600, Tim Altman wrote:
>
>> I'm sure Matthew will be happy to chime in and point out the flaws in
>> Jonny's work, but that point is moot now as someone else is working on
>> finishing Jonny's work and I don't even know if Jonny's original
>> design is being used. The performance improvements
>> released by the new developer's work are very significant
>> (on the order of 50x faster in some cases).
[...]
>Will all web sites now display in virtually zero time?
No. Some cache operations will be up to 50x faster. Viewing a Web
page is, of course, more complex than just caching a document.
>I am a user that requires that the cached files have file extensions.
>I use the cache file extensions every day to locate articles that
>I recall seeing.
Is there any reason you can't use opera:historysearch?
"self"
>> I am a user that requires that the cached files have file extensions.
>> I use the cache file extensions every day to locate articles
>> that I recall seeing.
TA:
> Is there any reason you can't use opera:historysearch?
With "empty on exit" _not_ checked (to bypass the bug you pointed out),
I've just displayed Google News (with many JPG images) with 9.62,
tried opera:historysearch for "jpg" and got one result
(not from Google News)
I suppose this is not meant as a search for cache files,
but it illustrates again that replacing all of Windows Explorer's
many powerful and efficient features (and complete system integration)
with various weak, limited, and often ineffective work-arounds is a bit like
cutting off one's hand and asking whether a hook will do in its place.
Please forgive my final "beating the drum" -- I'll probably retire for the season,
having done my best in a campaign to highlight the fundamental issue,
at least for the understanding of those not directly experiencing it.
Season's Greetings!
--
> 1) How do you interact with the cached files, i.e. what doesn't work
> in 9.5+ that does work for you in 9.27-?
I use external text editor for viewing/editing of problemmatic web
pages (seeking Opera bugs or trying to find quick fix for web pages at
work). "Live editing" of any page source file (HTML, CSS, JS) is the
main reason why I use Opera for this, and I need proper source
highlighting and auto-completion of code for every sort of file type.
Also sometimes I use cache in direct way when I want so save some
video file (SWF, WMV, MOV, etc.). Main reasons: I don't remember where
I saw this video, I dont want to redownload it to save, I can't save
it directly from web site. I use console program FAR Manager (Norton
Commander friend) to sort files in cache and do whatever I need to do.
> 2) Could enhancements to opera:cache work-around not having file
> extensions on cached files? If so, what enhancements? For instance,
> if the MIME type or file extension were listed in opera:cache, would
> that be a satisfactory solution?
For source viewing/editing -- no, opera:cache can't help.
For video file saving opera:cache can help if it will be improved:
sorting and improved overall usability of cache manager will do the
thing for me.
> 3) How are you working around the removal of cache files, i.e. are you
> using 9.5+ with a different work flow from 9.27?
I use Opera 9.27 at work where I use "live editing" feature alot. Also
I need good old proper detach of a tab, but this is another story. ;)
For video saving I also use Opera 9.27 or if video is Flash I can use
UserJS for this.
> Also sometimes I use cache in direct way when I want so save some
> video file (SWF, WMV, MOV, etc.). Main reasons: I don't remember where
> I saw this video, I dont want to redownload it to save, I can't save
> it directly from web site.
For that I use the thunbnail preview and sorting from
http://my.opera.com/Lex1/blog/show.dml/1014525
to look what is in the cache...
--
Gruß / Regards | e-mail is valid, don't remove NOSPAM!
Roland Reck | http://quhno.internetstrahlen.de/
>I posted some complains and other thoughts on Opera forum, but I see
>here some structured questions, so I want to add my usage case. I will
>try to be short and clear.
>
>> 1) How do you interact with the cached files, i.e. what doesn't work
>> in 9.5+ that does work for you in 9.27-?
>
>I use external text editor for viewing/editing of problemmatic web
>pages.
What editor do you use?
[...]
>Also sometimes I use cache in direct way when I want so save some
>video file (SWF, WMV, MOV, etc.).
OK.
>> 2) Could enhancements to opera:cache work-around not having file
>> extensions on cached files? If so, what enhancements? For instance,
>> if the MIME type or file extension were listed in opera:cache, would
>> that be a satisfactory solution?
>
>For source viewing/editing -- no, opera:cache can't help.
OK.
>For video file saving opera:cache can help if it will be improved:
>sorting and improved overall usability of cache manager will do the
>thing for me.
OK.
>> 3) How are you working around the removal of cache files, i.e. are you
>> using 9.5+ with a different work flow from 9.27?
>
>I use Opera 9.27 at work where I use "live editing" feature alot. Also
>I need good old proper detach of a tab, but this is another story. ;)
>For video saving I also use Opera 9.27 or if video is Flash I can use
>UserJS for this.
OK.
>On Tue, 02 Dec 2008 11:15:27 -0600, Tim Altman wrote:
>
>"self"
>>> I am a user that requires that the cached files have file extensions.
>>> I use the cache file extensions every day to locate articles
>>> that I recall seeing.
>
>TA:
>> Is there any reason you can't use opera:historysearch?
>
>With "empty on exit" _not_ checked (to bypass the bug you pointed out),
>I've just displayed Google News (with many JPG images) with 9.62,
>tried opera:historysearch for "jpg" and got one result
>(not from Google News)
Right. opera:historysearch works based on the text in pages. So, it
could work for self's use case, but not yours.
>I'm posting this using the latest Opera 10 snapshot, and I'm sad to see
>that extensions are not back...
>I really hope to see them in the final release.
They will not be. The cache back-end work being done is for a future
release.
Well, I used TopStyle, PSPad and Notepad++ (the one I'm currently
using).
If you are going to suggest me to set editor's default type of
document to HTML, then I know this option, but as I said before I view/
edit different source files (HTML, CSS, JS, XML).
Someone here suggested to add ability to set different document types
to different external editors. All I can say -- this would be
fantastic!
I would set HTML and CSS to TopStyle, JavaScript to Notepad++ and XML
to Microsoft XML Notepad.
> Veggen Skrikk wrote:
>
>> User-Agent: Opera Mail/9.62 (Win32)
>>
>> I'm posting this using the latest Opera 10 snapshot,
>>
>
>
> Hmm...
>
LOL :D
They were both open at the same time (still are, as I'm playing with the
new alpha), I didn't even notice...
Yes, I cannot use opera:history search because I remove all cached files
periodically (and then erase all but the htm and html files) I keep
these htm and html files in a directory separate from Opera. Where they
are indexed by Copernic.
If I did not remove all the cached files periodically from Opera the
browser would take a long time for my Opera browser to open ( we are
talking about 10k's of files, and Gigs of memory because I keep archived
all of these htm and html files since the beginning of my browsing years
ago.)
--
Pat
> At the risk of opening a can of worms, I'd like to ask some questions
> to those that require cached files to have file extensions.
For me, it's mainly using my external source viewer, which is editplus.
Editplus decides file type based on file extension (you can change it once
the file is open). A workaround might have been to treat no extension as
html, but I can't see a way of adding "no extension" to the HTML list. It
does have a first line sniff, so any files using a <!DOCTYPE will be
detected ok.
I might also want to capture flash video from cache, but have only
actually done it once so far.
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
OK. Hopefully the cache back-end redesign will resolve that problem.