Branches
Comments
[»]
possible conflict between this and GTK+ objects
by Kang, Jeong-Hee - Mar 3rd 2003 12:51:57
GTK+ has GLib the good set of objects and functions.
and GLib 2 provide GCache and GSource, etc.
I'm afraid that someday this project and python port of GTK+ make conflict
over names.
--
from [ke'izi] : where is [r]?
[reply]
[top]
[»]
Re: possible conflict between this and GTK+ objects
by abo - Apr 16th 2003 02:42:45
[...]
> I'm afraid that someday this project and
> python port of GTK+ make conflict over
> names.
I just got an email enquiring about a gcache failure in apache and the
apache-ssl module. Is this the GTK+ gcache, or yet another one?
Probaby this project should have it's name changed to pyGCache... hmm now
how do I go about that...
[reply]
[top]
[»]
Re: possible conflict between this and GTK+ objects
by jeff covey - Apr 16th 2003 06:14:48
> Probaby this project should have it's name changed to
> pyGCache... hmm now how do I go about that...
Use the "update project" function on the "[Project]" menu.
--
vs lbh pna ernq guvf, lbh'er n trrx.
[reply]
[top]
[»]
Re: possible conflict between this and GTK+ objects
by abo - Oct 16th 2006 13:12:09
>
> % Probaby this project should have it's
> name changed to
> % pyGCache...
done. Also licence changed to LGPL.
[reply]
[top]
[»]
Version 1.7 much better.
by abo - Nov 20th 2001 18:50:34
The version 1.7 significantly re-structured GCache from the previously
released 0.1. The MetaData class is gone, instead a GSource class is used
to create generic sources that produce (meta,data) tuples. New caches are
no-longer implemented by inheriting from GCache and defining source_get
methods, instead, GCache instances are created with a GSource instance
parameter that implementes the upstream source interface.
This significantly cleans up the class heirachy, making everything simpler
and more powerful. Defining GSource source's for a cache is much simpler,
making GCache easier to use. Note that GCache is itself inherited from
GSource, allowing for GCache instances to have other GCache instances as
their source, allowing for cache heirachys.
The use of tuples and integer timestamps has significantly reduced the
memory overheads. The dependance on PQueue has been removed by providing an
optional pure Python implementation of PQueue. A persistant PCache has also
been provided that incidentaly also reduces the memory overhead by storing
cache contents in a shelve.
The API has also been significantly changed to allow for any sort of
refresh-update, including rsync style delta updates as well as
If-Modified-Since fetches. All of this is hidden behind the simple Python
dict interface.
[reply]
[top]
[»]
New version soon...
by abo - Jan 23rd 2001 01:52:00
There is a new version of this coming soon. I have updated the API to
support delta-based updates, inspired by rproxy, in addition to
if-modified-since fetches. There will also be some additional tweaks and
example applications.
[reply]
[top]
[»]
Needs PQueue; where to get it.
by abo - Nov 16th 1999 07:33:13
G'day,
Just looked at my logs and saw quite a few people have downloaded this.
You will definitely need the PQueue module to make use of it, unless you
want to substantialy hack it to use some other priority queue data
structure.
Because the PQueue module can be hard to find, I've just added an appindex
entry for it that should show up soon. For those who can't wait, it's also
available in the same
directory where I've put PQueue.
[reply]
[top]
|
