Don't forget mongodb and riak. Both already have pharo support (especially mongo).
cheers, Esteban
On Jul 25, 2012, at 8:56 AM, Tudor Girba wrote:
Hi,
A topic that was raised recently is the scalability issue of Moose. Indeed, it would be great to have again some traction in this direction.
I think there are a couple of possibilities in this area:
Gemstone. This is the straightforward idea and it would probably match quite well the FAMIX object-oriented model. The realization might not be that easy because we would need to go through all the details of the language independence. Also, we would need a remote UI, or at least a bridge for Glamour. Perhaps the Seaside interface of Glamour, or another Seaside-based one, would be a good direction.
Graph DBs. http://neo4j.org/ would be an interesting target here. I have no experience in this area, but I would be very interested in collaborating with someone on this.
Relational DBs. I know that Marco D'Ambros worked on a solution to map FAMIX meta-descriptions to Glorp in VW. And it seemed to work. I think Alberto Bacchelli is or has used it.
Fuel. Loading with Fuel is about one order of magnitude faster than loading plain MSE: for example for ArgoUML 0.32 I got 108s for the MSE, and 17s for the Fuel based MSE information. So, having the Fuel export next to the MSE file can be a significant improvement. However, this solution only works when you have computations that treat one model at a time (so, it's not so nice if you have to switch between models all the time). I attached a simple script to analyze the difference between plain MSE loading and Fuel load variations.
Filtered loading. This solution works well when you have the full model, but you do not need all of it. FMMetaRepositoryFilter offers the infrastructure for a filtered loading at the level of FAME: if you want to load a sub part of your model, you construct a sub-meta-model and then let Fame do the rest. This kind of works, but it is only available at the moment in code (look at the tests). We need to move to the next step of integrating this solution and replace the MooseImportingContext and possibly offer a UI as well.
If you want to pick up on any of these topics, let's open a separate thread and see what we can do.
Cheers, Doru
-- www.tudorgirba.com
"We can create beautiful models in a vacuum. But, to get them effective we have to deal with the inconvenience of reality."
<mse-vs-fuel.txt>
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev