> So, here's the problem. Perhaps someone here has an insight that can 
> help solve it. (For more detail, read the OB paper that was recently 
> announced here.)
> 
> The behavior of each browser is governed by a metagraph. A metagraph is 
> a DG, consisting of nodes connected by directed edges. The graph can 
> have cycles, and they frequently do. Both nodes and edges can have 
> additional attributes attached to them. We need to be able to 
> programmatically build a metagraph in such a way that the code used to 
> build it can be dynamically discovered, can reside in several different 
> packages, can affect the structure of the graph without overriding code 
> in another package, and be composed without risk of creating invalid 
> graphs.

I don't have a clever solution for that problem, unfortunately, but I would like to 
mention another problem with OB that is troubling me a bit.

I dream of having a framework which allows me to put different browser elements 
together in any possible combination. For instance, I would like to be able to add a 
column on the left side of the definition panel, or I would like to have multiple 
definition panels to provide multiple selection for methods or classes. Or then I 
want to have a column which includes two "sub-columns".

While it is possible to implement these kind of things with OB, it requires me to 
"hack" around deep in the framework to actually realize such things. Because OB is 
quite restricted, for instance there is always this left to right navigation approach 
for the columns, providing another navigation approach than that is almost 
impossible. But doing so nevertheless leads to a completely separated branch of OB 
which probably can never be merged back to the original OB.

My question now is if i am better off implementing my own framework to do these kind 
of things, or if it is worthwhile to think about possible solutions to make OB so 
flexible and generic that even these "special" things can be achieved without having 
two completely separated branches of OB?
I would personally prefer to have only one branch of OB, or maybe another branch 
being only slightly different, but I would be very interested to see what others think?

I believe OB is really great in implementing that kind of browsers that exist right 
now in Squeak, strictly following the navigating and browsing pattern typically to 
Squeak. But when it comes to experiment with some other approaches to navigate, 
browse and maintain source artifacts then OB is probably too restricted right now. So 
I am wondering if there is a motiviation to make the OB framework even more flexible 
to be able to use it also for experimental browsers following new concepts of 
browsing, or if OB should "just" be and remain a better framework to implement 
standard browsers in Squeak?

Thanks for any comments on this.

Kind regards,
David