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:

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 Pharo-project@lists.gforge.inria.fr 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