---------- Forwarded message ----------
From: Alberto G. Corona <agocorona@gmail.com>
Date: 2008/10/29
Subject: Re: [Haskell-cafe] ANNOUNCE: Data.TCache 0.5.1
To: Joachim Breitner <mail@joachim-breitner.de>

I developed it in 2006. At this time I think that Happs did not used STM. I do not know Happs.State very well. The main difference is that it is far far simple (only a handfull of methods exported) it is configurable and permit the full semantic of TVars without loosing content persistence. Also, the query is based on let´s say patterns. A pattern is a partilally filled object. enough to deduce the key. the interface is very natural. For example:

withResources [ User{ name= "Alberto"} , Product{ id="Playstation"} buyIt
where
buyIt [Just user, Just product]= [user{due= due user +price product}, product{ stock= stock product -1]]
buyIt _ = error "either the user or the product not found"

Just prod <- getResource Product{ id="Playstation"}

bla bla bla

2008/10/29 Joachim Breitner <mail@joachim-breitner.de>

Hi,

Am Dienstag, den 28.10.2008, 23:26 +0100 schrieb Alberto G. Corona :

> Data.Tcache is a transactional cache with configurable persistence. It
> tries to simulate Hibernate for Java or Rails for Ruby. The main
> difference is that transactions are done in memory trough STM. There
> are transactional cache implementations for some J2EE servers like
> JBOSS.
>
> TCache uses STM . It can atomically apply a function to a list of
> cached objects. The resulting objects go back to the cache
> (withResources). It also can retrieve these objects (getResources).
> Persistence can be syncronous (syncCache) or asyncronous, wtih
> configurable time between cache writes and configurable cache
> clearance strategy. the size of the cache can be configured too . All
> of this can be done trough clearSyncCacheProc. Even the TVar variables
> can be accessed directly (getTVar) to acceess all the semantic of
> atomic blocks while maintaining the persistence of the TVar updates.
>
> Persistence can be defined for each object.: Each object must have a
> defined key, a default filename path (if applicable). Persistence is
> pre-defined in files, but the readResource writeResource and
> delResource methods can be redefined to persist in databases or
> whatever.

Interesting. Without much deep knowledge, this sounds similar to
HAppS.State. Where are the differences?

Greetings,
Joachim

--
Joachim "nomeata" Breitner
mail: mail@joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C
JID: nomeata@joachim-breitner.de | http://www.joachim-breitner.de/
Debian Developer: nomeata@debian.org

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe