작년 11월에 Digia는 Qt WebEngine이라 불리는 새로운 프로젝트를 시작했습니다. Google의 Chromium에 기반한 이 프로젝트는 현재의 Qt WebKit을 대체할 목적으로 만들어졌습니다. 대부분의 사람들은 Chromium을 쉽게 자신들의 프로젝트에 도입할 수 있게 된다는 사실을 크게 반겼습니다. Digia는 Qt WebEngine이 Qt WebKit과 가능한 한 최대한 호환되도록 만들겠다고 약속하였고, 당대에서는 Nokia의 환경에서도 Digia가 꽤 좋은 평가를 받았던지라 많은 사람들이 그 약속을 믿었습니다.
지난주에 Qt WebEngine 팀이 새로운 블로그를 올렸고, 저는 그 글의 댓글에서 API에 대한 약간의 “불평”을 발견했습니다. 위키를 확인해본 결과, 제가 web crawler 개발에 사용하는 핵심 기능인 QWebElement는 사용 불가로 낙인이 찍혀 있더군요 - 위키에 따르면, Chromium 자체가 멀티프로세스 기반이다보니 이 기능 자체가 비동기적으로 구성되어야 하는데, Qt WebEngine의 디자인은 동기화 구성이 기본이라 더이상 지원하지 않는다고 합니다.
QWebElement뿐만이 아닙니다. 제가 컨텐츠의 정상 여부를 활용하는데 사용하는 QNetworkAccessManager도 사용되지 않습니다. Qt WebEngine은 Chromium의 자체 네트워크 스택을 사용하며, 이렇게 되면 전 엔진의 네트웍에서 무슨 일이 벌어지는지 가늠할 수 있는 방법이 없어집니다.
덕분에 전 제 개발품에서 일부 기능을 부득이하게 삭제해야 되는 상황에 처했습니다. 일단 예측 가능한 미래만 놓고 본다면, Qt WebKit 자체는 9월 발표 예정인 Qt 5.4가 나오는 11월까지는 어떻게든 생존하겠지만, Qt 5.5 오픈소스 에디션이 발표되는 순간 무슨 일이 생길지는 아무도 모릅니다.
그간 WebKit이 유지보수에 손이 좀 많이 갔다고 하기도 하고, 저는 Digia의 개발팀을 좀 더 “효율적으로” 관리하고자 하는 의지 또한 존중합니다. 허나, 지난주 블로그 포스트에 달린 댓글들마냥 Qt WebEngine이 기대와 다르게 훨씬 더 적은 기능만을 갖고 출시된다면 아마 실망하는 사람이 적잖을 것 같아 우려됩니다.
현재 저는 현재의 개발환경을 대체할만한 무언가를 찾고 있습니다. Qt가 그동안 버전업을 하면서 셋업은 복잡해지고, QML 시작은 느려지고(빈 창 하나 띄우는데 최고 10초까지 소요) 하는 등의 상황을 보면서 뭔가 제 마음에 들만한 대체요소를 찾고 있긴 했습니다만, 울고 싶던 차에 Qt WebEngine이 뺨을 제대로 때려주는군요. 일단 현재는 wxWidgets+wxWebConnect(아니면 wxWebView) 컴보를 대체품으로 생각하고 있습니다.
어쨌든, Qt WebKit은 꽤나 위대한 프로젝트였습니다만, 이 프로젝트가 역사 속으로 사라질걸 생각하니 참 가슴이 아픕니다. 특히나 그렇게 사라지는 행위가 제 뒤통수를 크게 때리는 경우에는 더 그렇습니다.
A blog from a software developer who didn't get any formal training or education at all. :P
Sunday, May 18, 2014
Seeing the Doomed, yet Great Project: Qt WebKit
Last November, Digia announced the start of the new project named Qt WebEngine. Based on Google Chromium, it is a drop-in replacement of Qt WebKit. Most of the people welcomed the project, as they can easily use Chromium and Blink to their own environment. Digia said that Qt WebEngine will be as compatible as possible against Qt WebKit, and everybody belived in the promise, as Digia had a good reputation against Nokia, as they were practically leading the project well even in Nokia days of Qt.
Last week, I read a new blog article from Qt WebEngine team, and I saw some “complaints” about APIs for the new module. I jumped to the wiki and found out that my beloved QWebElement, which is the most needed core feature for my web crawler engine, will be unavailable in Qt WebEngine - according to the wiki, due to multi-process nature of the Chromium the feature should be designed asynchronously, but the design of Qt WebEngine is synchronous, it is not supported anymore.
Not only QWebElement. It also doesn’t integrate QNetworkAccessManager, which is another thing I use to check sanity of the content. Qt WebEngine uses Chromium’s own network stack, meaning I cannot review any network action from the Engine.
Thanks to the changes, my product won’t be able to support some of the features it currently has. From the foreseeable future, Qt WebKit will survive until Qt 5.4, which is expected to be released at this September, but there’s no guarantee what’ll happen when Qt 5.5 open source edition is released.
Of course there are be some reasons beyond giviing up WebKit as it requires more manpower for maintenance and I respect their decision to manage their development team in “more efficient” way. Yet I’m afraid there will be more who’re frustrated against new Qt WebEngine for its limited features as I read from some replies for Qt WebEngine blog article last week.
Well, now I search for some alternative development environment. I was already searching for a replacement of Qt itself as I see it become feature-bloat, resulting in more complicated setup environment, slow startup time in QML(up to 10 seconds for showing blank window), as I adopt new version of the library. And Qt WebEngine accelerated my move. Currently I consider wxWidgets+wxWebConnect(or wxWebView) combination as a replacement for current development environment.
Anyway, Qt WebKit was a great project, yet seeing one of the greatest development projects fade out to the history is quite a pain. Especially if the fadeout directly hits me hard.
Last week, I read a new blog article from Qt WebEngine team, and I saw some “complaints” about APIs for the new module. I jumped to the wiki and found out that my beloved QWebElement, which is the most needed core feature for my web crawler engine, will be unavailable in Qt WebEngine - according to the wiki, due to multi-process nature of the Chromium the feature should be designed asynchronously, but the design of Qt WebEngine is synchronous, it is not supported anymore.
Not only QWebElement. It also doesn’t integrate QNetworkAccessManager, which is another thing I use to check sanity of the content. Qt WebEngine uses Chromium’s own network stack, meaning I cannot review any network action from the Engine.
Thanks to the changes, my product won’t be able to support some of the features it currently has. From the foreseeable future, Qt WebKit will survive until Qt 5.4, which is expected to be released at this September, but there’s no guarantee what’ll happen when Qt 5.5 open source edition is released.
Of course there are be some reasons beyond giviing up WebKit as it requires more manpower for maintenance and I respect their decision to manage their development team in “more efficient” way. Yet I’m afraid there will be more who’re frustrated against new Qt WebEngine for its limited features as I read from some replies for Qt WebEngine blog article last week.
Well, now I search for some alternative development environment. I was already searching for a replacement of Qt itself as I see it become feature-bloat, resulting in more complicated setup environment, slow startup time in QML(up to 10 seconds for showing blank window), as I adopt new version of the library. And Qt WebEngine accelerated my move. Currently I consider wxWidgets+wxWebConnect(or wxWebView) combination as a replacement for current development environment.
Anyway, Qt WebKit was a great project, yet seeing one of the greatest development projects fade out to the history is quite a pain. Especially if the fadeout directly hits me hard.
Wednesday, May 7, 2014
The Power to Think for Oneself
Do not force them to think. From the beginning they didn’t even try to think at all. They just followed others’ thoughts and thickened thoughts that way.
Subscribe to:
Posts (Atom)