On Mon, 2010-04-26 at 23:29 +0100, Lucian Branescu wrote: > This is part of why I think having an abstraction layer is more > important than having a complete pywebkitgtk browser activity. > > I would be even cooler if Read could also use this abstraction layer for epub.
Now it makes sense. As long as there's only one activity using this abstraction layer, it wouldn't make sense to have it as a separate module. But careful: designing glue code of this kind is really hard. They're really bridges with an abstract API on each side. The Linux vfs layer would be a good example. Many iterations may be necessary to refine the interface before it can be considered stable on both side. These things also tend to make debugging very hard, because they introduce 2-3 additional layers of indirection between the user interface and the engine doing the actual work on its behalf. To slightly reduce the overall complexity, one may think to fold hulahop into one of the concrete browser implementations and remove most of the excess flexibility that it delivered. Anyway, Browse appears to be the only user of hulahop in the entire universe, so it would have been stupid to maintain in separately. This is of course just the personal opinion of a minimalist embedded engineer who hates unnecessary abstractions. I'm aware that innumerable books of mainstream software engineering encourage a diametrically opposite approach. In support my demodé opinion, consider that among the production-quality browsers, only Epiphany attempted to abstract away the differences between Mozilla and Webkit. However, after a while they decided it was too much work for too little benefit. Eventually, they discontinued Mozilla support. Epiphany was trying to solve just one half of the whole problem of mediating between multiple applications and browser engines. KDE's KPart would be closer to what you want to do, but after several years of struggling, the webkitpart still hasn't reached the point of usability. That said, I'm not familiar with the details of any of the APIs in question. It may very well be overestimating the actual complexity and the other projects I mentioned might have just been unlucky or mismanaged. > On 26 April 2010 21:10, Sayamindu Dasgupta <sayami...@gmail.com> wrote: > > On Mon, Apr 26, 2010 at 2:18 PM, Lucian Branescu > > <lucian.brane...@gmail.com> wrote: > >> There already is a mostly complete pywebkitgtk activity, Surf. > >> > >> There has been a lot of debate on whether webkit is better than gecko > >> for our purposes. I also plan to only support what is reasonably easy > >> to support and let the abstraction layer be leaky. > >> > >> This way, the new Browse can much more easily be ported to another web > >> engine if needed. In fact, as the abstraction layer grows more > >> complete, Browse can be 'ported' to the rest of the abstraction layer > >> (as opposed to AbstractBrowser+hulahop events which would be the first > >> step). > >> > > > > Something which concerns me is the relative lack of maintainer > > activity for pywebkitgtk. For example, > > http://code.google.com/p/pywebkitgtk/issues/detail?id=44 lists an > > issue which was reported in December last year, and there has been no > > feedback on it (there is a proposed patch as well). The fix for the > > issue would help address a few crashers in Read in F-12 and above. > > Of course, as we move to gobject-introspection and friends, this > > should become less of a concern. > > Thanks, > > Sayamindu > > > > > > > > > >> On 26 April 2010 03:20, Bernie Innocenti <ber...@codewiz.org> wrote: > >>> On Sun, 2010-04-25 at 18:07 +0100, Lucian Branescu wrote: > >>>> My GSoC project involves building an abstraction layer above > >>>> pywebkitgtk/hulahop (wiki/AbstractBrowser). > >>>> > >>>> While the project itself isn't related, this abstraction layer and one > >>>> of it's lower layers (i.e. pywebkitgtk) would become a dependency of > >>>> the sugar toolkit. > >>> > >>> Very interesting. Would your work make it possible to switch the Browse > >>> activity from XPCOM to Webkit? > >>> > >>> If there were no loss of features, would it be easier for you to switch > >>> the Browse activty from hulahop to pywebkitgtk without developing an > >>> abstraction framework for both? > >>> > >>> -- > >>> // Bernie Innocenti - http://codewiz.org/ > >>> \X/ Sugar Labs - http://sugarlabs.org/ > >>> > >>> > >> > > > > > > > > -- > > Sayamindu Dasgupta > > [http://sayamindu.randomink.org/ramblings] > > > -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel