question about O2 vs OB

Hi, was wondering why we need O2 and OB as two different frameworks?, and why O2 is not an extension to OB, are they structurally different in design and implementation?

I was wondering about this since i read the last emails about O2 and OB decoupling.

Because now if we reintegrate O2, the system will have much more complexity.

Thanks,

Fernando
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

O2 is a fork of OB.

The duplication of the complete code-base is necessary, because O2
makes incompatible changes to the OmniBrowser framework. The way O2 is
implemented makes it impossible to run both together on the same core
model without conflicts.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Ok, thanks for the answer Lukas.

 Then i would ask the O2 developers, why is the fork needed? Just curious, because if 02 copies a lot from OB, to add more functionality why that extra features cant be part of OB?

My point is that i don't understand if OB is no extensible enough for building O2, or just because it was easier to fork.

Many thanks,
Fernando

 
On Jan 20, 2010, at 2:14 PM, Lukas Renggli wrote:


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

>  Then i would ask the O2 developers, why is the fork needed? Just curious, because if 02 copies a lot from OB, to add more functionality why that extra features cant be part of OB?

I don't know, but I guess one of the reasons is that there is not a
single test case for any of the new functionality. In comparison the
OB code-base is extremely well tested, it has a very high
code-coverage and even the morphic GUI code has tests.

Another problem is that the O2 code does not use the meta-model
everywhere, some parts are just hardcoded. Also its code is not
properly packaged, so the very generic framework to build browsers
suddenly includes behavior that just make sense for some specific
Smalltalk code browsers.

Furthermore OB is designed to be platform independent (like Seaside).
The same code is for example used in GemStone and Squeak. O2 is full
of platform dependent code.

It's a pity because OB could be really much more powerful.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Hi Fernando,

>  Then i would ask the O2 developers, why is the fork needed? Just curious, because if 02 copies a lot from OB, to add more functionality why that extra features cant be part of OB?

We didn't fork O2 from OB for the longest time. Instead what is in O2 now was just a
package called OB-Enhancements that could be loaded in OB to get the package browser and
some other extensions to OB now being part of O2.
But while this situation had the benefit of reusing the entire OB framework, which I
really liked to re-use, the disadvantages were that this framework really restricted the
possible extensions to the browser. So I had to change and adapt the framework itself. Now
there were people that did not like these extensions, might it be because they did break
their external tools based on the OB framework, might it be that these extensions also
changed some behavior of the traditional OB-based code browser, or might it be that the
changes were not well enough tested and thus it happened that there were bugs in the OB
browser itself here and there. Also it was not possible to make these changes to the OB
code and still keep the same behavior in all browsers as it used to be before.
Furthermore, it got difficult for people fixing bugs in their forks of OB and merging them
back to the now changed OB framework.
Eventually, there was also a lack of lead concerning integration and maintenance of OB
itself. Nobody felt responsible to take this lead. Colin was the original developer of OB,
but he couldn't spend too much time on it anymore. I just wanted to extend OB to do some
enhancements to it, but saw that this is not possible without extending its core. As I
felt like you and did not want to fork, I extended the core itself in Colin's repository.
But this turned out to not be compatible with the wishes of the community, so we forked O2
away.

That's the reason of having OB and O2. While both now work together in the same image
without inferring each other, this indeed increases the number of classes in the image
quite a lot as they duplicate a whole bunch of code. So I strongly suggest to either use
OB or O2, even though you can have both. But I do not see a reason why people want to
switch between the two dynamically in the same image.

Cheers,
David

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project