On Wed, Oct 2, 2013 at 5:13 PM, Stéphane Ducasse <[email protected]>wrote:
> Mariano > > why 1Gb and not tomorrow afternoon 5 Gb and in two days 10 Gb? > Yes, it will probably be like this. But by then time I use 5GB my server will probably have 100GB by then. > Of course Pharo is limited and I hope that with the new Cog > Indeed, I hope it too. And yes, it seems this will change with what Eliot is doing. > it will be different but soon it will not fit in the ram of your OS. > > Stef > > > > On Wed, Oct 2, 2013 at 4:42 PM, Sven Van Caekenberghe <[email protected]>wrote: > >> Mariano, >> >> On 02 Oct 2013, at 20:49, Mariano Martinez Peck <[email protected]> >> wrote: >> >> > Hi guys. >> > First, let me apologize for the amount of emails I am sending. I am >> doing an analysis to see if GemStone is a good candidate for a project I am >> working and so it deserves some research. >> > >> > I wondered if any has ever tried porting any of these tools to >> GemStone: Fuel, Glorp, Native PostgreSQL driver, Voyage and MongoDB. >> >> I do not understand. >> >> IMHO there is only one reason to go to Gemstone, and that is to use its >> capabilities as OODB. All the technologies you mention are persistency >> related and would not be needed in that case, right ? >> > > More or less. Fuel would be awesome to move data between Pharo and > GemStone. SIXX has demonstrated some limitations. > And regarding Glorp / native postgres driver and Voyage/Mongo is because > what I may store in GemStone is not the only DB in the game. I may have > OTHER DBs that for a reason not important here, should remain either in a > relation DB or in Voyage. Yet, I need to query them somehow from Pharo. Of > course, I can have a Pharo image that does the job and provides > web-services (or anything similar) to my GemStone....but of course it is > easier if these DB clients would work in GemStone as well.... > > >> >> As you most probably know, you can get pretty far with Pharo. > > > Yes I know. But this particular application may have a lot of data > processing, algorithms, etc, which may probably NOT fit in 1GB of memory > and the effort to distribute the process among multiple images could be > high. > > >> After that, there is load-balancing, partitioning, message queues. Pretty >> much what any technology stack does. >> >> > Indeed. But I would still need a persistency solution that satisfy all my > needs. I should write this down and compare the alternatives in Pharo. > > >> You will always find more tools and libraries on the Pharo side, as the >> community is much larger. >> >> > Sure. But at least I would only miss the "deployment" libraries, since in > any case I will continue developing in Pharo, so all the development tools > and all the environment will be the same. > > > Thanks for the discussion! > > > > -- > Mariano > http://marianopeck.wordpress.com > > > -- Mariano http://marianopeck.wordpress.com
