On 21 Jul 2014, at 3:34 , Esteban Lorenzano <
estebanlm@gmail.com> wrote:
On 21 Jul 2014, at 09:44, stepharo <stepharo@free.fr> wrote:
On 21/7/14 08:46, Torsten Bergmann wrote:
DALI
http://ss3.gemstone.com/ss/DALi.html
VOYAGE
http://smalltalkhub.com/#!/~estebanlm/Voyage
I do not know if there are back ends for something else than mongo in Voyage.
certainly not for GOODS :)
actually we have just �in memory� and �mongo� (in memory works fine when deploying on gemstone, for example)
I always want to add more backends but well� time, time, time�
Esteban
I�m intending to add one for Riak, in an unspecified amount of time, depending on my other workload�
I�d like it performant, and use a client up to date with the latest Riak API, which (afaict) means using the ProtoBuffer protocol, which means having to implementing PB first.
The progress so far is I got the PB serializer almost done (sidetracked by wanting an NB-based UTF8 converter to make it more performant), but I haven�t started the PB message parser yet, nor the actual Riak backend.
I was intending to add Riak support too :)
Do you want access to the repo, so we keep all together? (and then I can check and maybe collaborate)
and btw, are you using/checking Phriak?
Esteban
Sure, as you might have inferred from my mail, it�ll probably be a bit before I start on the actual riak client, though it�s in my plans.
First, I�ll need to finish up and release NBConverters (of which UTF8 conversion I want to use in PB implementation is a part), then Protobuffer implementation (data type serialization + message spec parsing), then parse in the Riak PB messages and build a client on top of that.
And yes, I�ve checked Phriak, building a client on top of that would probably be much faster than what I intend.
But, seeing as how there�s 2.0 functionality exclusively implemented in the PB API, I thought it�d be nice to go the long route while I�m at it.
AFAICT, 2.0 mostly adds functionality, so it seems to me if someone wrote a backend using Phriak, a new client would be able to operate as a drop-in replacement if it is indeed more performant. (not to mention a nice starting point for a 2.0 backend which can utilize new functionality)
Cheers,
Henry