DALI
http://ss3.gemstone.com/ss/DALi.html VOYAGE http://smalltalkhub.com/#!/~estebanlm/Voyage Any experiences to share about pro and cons? Thanks T. |
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. > > Any experiences to share about pro and cons? > > Thanks > T. > > |
On 21 Jul 2014, at 09:44, stepharo <[hidden email]> 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 > >> >> Any experiences to share about pro and cons? >> >> Thanks >> T. >> >> > > |
On 21 Jul 2014, at 3:34 , Esteban Lorenzano <[hidden email]> wrote: > > On 21 Jul 2014, at 09:44, stepharo <[hidden email]> 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’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. Cheers, Henry signature.asc (859 bytes) Download Attachment |
On 28 Jul 2014, at 11:15, Henrik Johansen <[hidden email]> wrote:
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
|
On 28 Jul 2014, at 11:36, Esteban Lorenzano <[hidden email]> wrote: > > On 28 Jul 2014, at 11:15, Henrik Johansen <[hidden email]> wrote: > >> >> On 21 Jul 2014, at 3:34 , Esteban Lorenzano <[hidden email]> wrote: >> >>> >>> On 21 Jul 2014, at 09:44, stepharo <[hidden email]> 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. It would be good to have a ProtoBuffers implementation that is separate. The same goes for the BSON implementation hidden in StHub. >> 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 > >> >> Cheers, >> Henry |
In reply to this post by Henrik Sperre Johansen
Am 28.07.2014 um 11:15 schrieb Henrik Johansen <[hidden email]>: > > On 21 Jul 2014, at 3:34 , Esteban Lorenzano <[hidden email]> wrote: > >> >> On 21 Jul 2014, at 09:44, stepharo <[hidden email]> 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. > Having a Riak backend for voyage would be great. But then there should be some notion to control indices, right? In MongoTalk and Voyage there is nothing like an index. For Mongo indices are separate from the data. In Riak they are not (really) because I think it only works performant if secondary indices are written (being meta/header data) when the data is written. Any opinion on this? Norbert |
In reply to this post by Sven Van Caekenberghe-2
Am 28.07.2014 um 11:41 schrieb Sven Van Caekenberghe <[hidden email]>: The BSON code should be loadable without MongoTalk. It is separate packages. Or do you mean a separate repository would be better? IMHO it would be sufficient to find it but smalltalkhub isn't helpful in this respect. Norbert
|
On 28 Jul 2014, at 11:45, Norbert Hartl <[hidden email]> wrote: > > Am 28.07.2014 um 11:41 schrieb Sven Van Caekenberghe <[hidden email]>: > >> >> On 28 Jul 2014, at 11:36, Esteban Lorenzano <[hidden email]> wrote: >> >>> >>> On 28 Jul 2014, at 11:15, Henrik Johansen <[hidden email]> wrote: >>> >>>> >>>> On 21 Jul 2014, at 3:34 , Esteban Lorenzano <[hidden email]> wrote: >>>> >>>>> >>>>> On 21 Jul 2014, at 09:44, stepharo <[hidden email]> 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. >> >> It would be good to have a ProtoBuffers implementation that is separate. >> The same goes for the BSON implementation hidden in StHub. >> > The BSON code should be loadable without MongoTalk. It is separate packages. Or do you mean a separate repository would be better? With separate I mean: being managed, documented, advertised, tested and used as such, it is more a mindset than how this is exactly done. Someone needs it for something new, point them to the right place and they are off. Protocols are (should be) ideal building blocks. But it _is_ more work than having it as a local subpart of some larger project. > IMHO it would be sufficient to find it but smalltalkhub isn't helpful in this respect. > > Norbert > >>>> 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 >>> >>>> >>>> Cheers, >>>> Henry |
Am 28.07.2014 um 11:51 schrieb Sven Van Caekenberghe <[hidden email]>: But it _is_ more work than having it as a local subpart of some larger project. Slightly ;) Who does not properly package and document his own stuff? Wait …. the original author seems to be a Kent Beck. Anyone knows him? :) Norbert
|
In reply to this post by EstebanLM
On 28 Jul 2014, at 11:36 , Esteban Lorenzano <[hidden email]> wrote:
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 signature.asc (859 bytes) Download Attachment |
In reply to this post by Sven Van Caekenberghe-2
On 28 Jul 2014, at 11:41 , Sven Van Caekenberghe <[hidden email]> wrote:
I agree, keeping the building blocks separate is nice :) Cheers. Henry signature.asc (859 bytes) Download Attachment |
In reply to this post by Sven Van Caekenberghe-2
On Jul 28, 2014, at 6:41 AM, Sven Van Caekenberghe <[hidden email]> wrote: It would be good to have a ProtoBuffers implementation that is separate.+1 The same goes for the BSON implementation hidden in StHub. |
Free forum by Nabble | Edit this page |