Closed MartinKersten closed 12 years ago
jheintz
commented
12 years ago Issue #18 for content caching - this is where I see history being able to play a general part in caching. Images, documents, whatever could all re "reload()"ed and check for etag and if-modified-since on the server-side. If a Resource were already in the History, we could implement interface Resource ... {
MartinKersten
commented
12 years ago I do not think the history should deal with images and other kind of resources.
For the reload, we can replay a request since every resource can have (and currently have) the request information being applied.
jheintz
commented
12 years ago But browsers currently support images and pdfs and .... as part of history.
Also, we don't want to just replay, we want to take advantage of #18 and provisionally get new content (or just used cached history.)
On Sun, Oct 14, 2012 at 3:36 PM, Martin Kersten notifications@github.comwrote:
I do not think the history should deal with images and other kind of resources.
For the reload, we can replay a request since every resource can have (and currently have) the request information being applied.
— Reply to this email directly or view it on GitHubhttps://github.com/GistLabs/mechanize/issues/49#issuecomment-9426629.
John D. Heintz Agile, Lean, and everything in between
President, Gist Labs http://gistlabs.com Senior Consultant, Cutter Consortium http://cutter.com
Austin, TX (512) 633-1198
MartinKersten
commented
12 years ago Well maybe we can provide a history and a filtered history (only a certain type of resource) but I do not know. You refer to cache often so I guess we are talking about a full cache (like the directories a browser uses for storing resources) and a history.
So I guess we should differenciate that. Also E-Tag and reuse would be possible to implement using the reload method. If something changed a all new resource is returned otherwise a resource where the document / content is shared and having a method like .hasChanged() is provided.
So: Image2 = image.reload(); if(image2.hasChanged()) -> all new else -> reuse buffer
So for this we don't need a cache at all. Just a container for resources a user can use. Maybe the cache is more optional. Remember if you have a history and lets say with a size of 20 you run into issues when you are getting all images the history has lost track of every document. So lets stick to history vs. cache. Maybe the history works with the cache but i do not think so.
2012/10/14 John Heintz notifications@github.com
But browsers currently support images and pdfs and .... as part of history.
Also, we don't want to just replay, we want to take advantage of #18 and provisionally get new content (or just used cached history.)
On Sun, Oct 14, 2012 at 3:36 PM, Martin Kersten notifications@github.comwrote:
I do not think the history should deal with images and other kind of resources.
For the reload, we can replay a request since every resource can have (and currently have) the request information being applied.
— Reply to this email directly or view it on GitHub< https://github.com/GistLabs/mechanize/issues/49#issuecomment-9426629>.
John D. Heintz Agile, Lean, and everything in between
President, Gist Labs http://gistlabs.com Senior Consultant, Cutter Consortium http://cutter.com
Austin, TX (512) 633-1198
— Reply to this email directly or view it on GitHubhttps://github.com/GistLabs/mechanize/issues/49#issuecomment-9428018.
MartinKersten
commented
12 years ago Finished. If we need additional support a Cache or something similar should be implemented or reload added to any of the resources
Why? I think History could evolve into a full cache and images would certainly be good for that.
On Oct 13, 2012, at 4:26, Martin Kersten notifications@github.com wrote:
— Reply to this email directly or view it on GitHubhttps://github.com/GistLabs/mechanize/issues/49.