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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch