Wander Alone Like A Rhinoceros Horn

WebKit2 was first disclosed to the public in April 2010. Now half a year has passed, has there been any noticeable progress? This time I delve into the WebKit2 from the source-code point of view. First let me recap what WebKit2 actually is and how it's related to the current WebKit with the official high level design document as the reference. For those who are not very familiar with WebKit, it may be confusing that WebKit as a whole contains a part that shares the same WebKit name. WebKit as the framework has 3 major components - WebKit , WebCore , and JavaScriptCore - as you see in the source directory . WebCore is the layout engine that parses an HTML5 web page into a DOM tree and renders a render tree created out of a DOM tree with CSS information computed on each node. In addition to the abstract or platform-agnostic parts, it contains platform-specific implementations such as graphics and I/O if necessary. JavaScriptCore is the JavaScript engine. Google Chrome swaps i...

The libevent library is probably best known by its use in memcached . memcached is one of the key components of the LAMP stack. However the recent trend seems to instead highlight NoSQL solutions where typical RDBMS and memcached are replaced with more optimized and dedicated systems. The importance of libevent is not affected at all by that trend since it's not tied to any applications and can be used for NoSQL solutions. Tor  is another use case of libevent. libevent is crucial for its cross-platform availability. One of the developers of libevent is Nick Mathewson who is also the key person behind the Tor project. My interest in libevent stems from my own project, the  DICE . From the beginning of the development in 2002, its I/O is fully optimized to Windows and I/O Completion Ports (IOCP) without using any middleware or libraries. Even though it works flawlessly in its current state, replacing it with a decent OSS library can be a good chance to make it more robust an...

Firefox 3.6から入った、chrome権限のJavaScriptから外部バイナリコンポーネントのネイティブ関数を呼び出す機構である js-ctypes の実装が、 libffi に基づいているということだったので、昔見たときはlibffiはVisual C++はサポートしてなかった記憶があったがFirefoxでビルドできるんだったら単体でもいけるよねーということで js-ctypesのソース を追いつつ試してみた。 結果から先に述べると、若干手間を要するものの問題なくビルドでき、closureも利用できた。ここでいうclosureとは、呼び出された際にユーザー指定コールバック関数(元の呼び出しに使われたlibffiフォーマットの引数データが渡ってくる)を起動してくれる関数コードを、ユーザーが動的に指定したシグニチャで、ランタイムに実行可能メモリ上に構築してくれるlibffiのAPIが用意されているので、それを利用して作成したバイナリコードを指す。 js-ctypes実装の構造は至極直截的で、JSのオブジェクトとネイティブオブジェクトのバインダとしての CTypes クラス と、dll/so/dylibみたいなバイナリコンポーネントのラッパーの Library クラス から成っている。 Library::Declare でシンボルからバイナリ内の関数アドレスを得るときは、 PR_FindFunctionSymbol を呼ぶ。これは NSPR の関数で、Windows上では、なんのことはない GetProcAddress が呼ばれる 。なんでlibffiなんてものが必要かというと、荒っぽく言ってしまえば、Cでは関数ポインタを宣言しておけばコンパイラが良きに計らってくれるところ、動的言語で同じことをランタイムに行うために、その辺の呼び出し規約上のお膳立てをlibffiが整えてくれるというわけだ。 上述のclosureは、js-ctypesでは、ネイティブコード側にJavascriptの関数をコールバックとして渡す時に利用されている。Javascript関数オブジェクトに関連づけたclosureを作成し、それが呼び出された場合には CClosure::ClosureStub が呼び出され、関連づけられていたJavascript関数オブジェクトが実行される...

5月21日に、 libutp ソースコードがMITライセンスで 公開された 。libutpとは、 µTP ( Micro Transport Protocol )と呼ばれるプロトコルの実装ライブラリである(BitTorrent.orgでは BEP 29 として提案され、IETFでは LEDBAT として提案された)。今回は、そのコードを見てみたい。 libutpを公開したのは BitTorrent, Inc. で、彼らが配布するBitTorrentクライアント μTorrent のバージョン1.8 betaがµTPを最初に実装した。BitTorrent, Inc.が元々持っていたオリジナルのBitTorrent実装(Mainline)は、Pythonで書かれたソフトウェアとして有名だが、μTorrentはC++で実装されたWindows用ソフトウェアである。μTorrentはスウェーデン人の Ludvig Strigeus 氏が開発したが、2006年にBitTorrent, Incに買収されている。μTorrentが登場したとき、備えている機能に比して、GUIアプリにしては(パックされている可能性を勘案しても)きわめて小さいバイナリサイズに感心した。プログラマの力量を誇示するかのようなコンパクトで尖ったソフトウェアだったので、後日の買収のニュースには、落ち着くところに落ち着いたなと感じたのを記憶している。 従来のBitTorrentによるファイル転送がTCPを経由して行われていたのに対し、µTPは、UDP上に構築されたプロトコルを用いる。既にDHTやトラッカーのプロトコルには UDPが利用されていた (ただしμTorrentによる実装はかなり後になった)が、µTPは、トランスポートプロトコルとしてもUDP上に構築した独自プロトコルを利用する。 BitTorrentクライアントが実装した DHT (分散ハッシュテーブル)は、 Kademlia というアルゴリズムの実装で、トラッカーに依存しないリソース探索が可能となった。Gnutellaライクな、しかしより構造化された分散キー管理により、トラッカーがダウンしていても目的のリソースを保持するピアのリストを得られる。ネットワークの単一障害点を無くすという建前だが、違法にアップロードされたデータを配布するトラッカーが検挙さ...

One thing that I don't like about scripting languages is usage of bizarre identifiers. Statically compiled languages don't care about verbose identifiers, but scripting languages often employ abbreviated names to gain run-time performance and typing speed. my ( $x, $y ) = $self->invoke( +{ METHOD => 'foo', PARAM => 'bar', }, '' ); In this Perl snippet, I had no idea what "+{}" stands for. It looks like some kind of hash, but not sure. Googling it didn't bring good results since Google doesn't recognize a string made only of non-alphabetical characters such as braces and math operators. To figure out its meaning I wasted so much time by trying many different words in Google. Anyway here's the answer: or to force an anon hash constructor use +{ : @hashes = map +{ lc ($_) => 1 }, @array # EXPR, so needs comma at end to get a list of anonymous hashes each with only one entry apiece. It's embedde...

Dependency Injection (DI) is one of the recent buzz phrases within the design pattern community after Martin Fowler picked it up with another related concept Inversion of Control (IoC) in 2004. Since then, it became popular in Java lightweight frameworks where adding late binding was seen as a critical step for upping productivity. The core value of DI is basically represented in these 2 points: Testability. DI makes testing easy by enabling loosely coupled components that are easily replaced with mock objects. Dependency control. When you deploy a DI framework instead of using the Factory Method pattern, dependency can be managed outside of components. The first point is rather obvious. To understand the second point, I recommend you to browse the Google Giuce lightweight Java DI framework for its video presentation and documents. It illustrates the necessity of such a framework for Java in a straightforward way. Particularly, Giuce appears to be a neat implementation of DI where y...

先月7月頭に、Googleの Chrome OS が発表された。Linuxカーネル + 軽量ウィンドウマネージャ + Google Chrome Webブラウザという構成を取るといわれるこのOSは、いわゆるシンクライアントを最低限のハードウェアリソースで実現するための環境となると推測される。ただし、従来の企業向け用途の単なるシンクライアントではなく、ビデオ再生や3Dなど、ハードウェアリソースを要求するリッチメディアがWeb上で当たり前のようにやりとりされている現在や近未来のパーソナルコンピューティング環境をも視野に入れていることは間違いないだろう。 これが、かつてOracleが提唱した ネットワークコンピュータ を越えていくものとなるかどうかは、実際のプロダクトの出来を見なければ、占うにはまだ早すぎるといわざるをえない。それでも、Google Chromeに続きChrome OSによって、Googleが考えるところの理想のクライアント環境を実現しようとする動きは、きわめて自然であるし、一貫性があるといえる。しかし、この一貫性は、単にGoogle内部で完結しているものではなく、歴史的な流れの中のある一点で、たまたまGoogleという企業が、マイルストーンとして一般に認知される発表を行うことを可能とするリソースや動機を有していた、という見方もできよう。 test 1 この仮想的な歴史をめぐる可能世界で、Chrome OSの前駆者として、またもう一つの可能性として念頭にあるのは、Microsoftの活動だ。今年の2月に発表された Gazelle は、プリンシパルベースのセキュリティという概念を主軸に置いて、Google Chromeより徹底したセキュリティアーキテクチャのWebブラウザを、OSをも巻き込んだ形で実装してしまおうという試みである。このアプローチは、Google Chrome実装の経緯と、興味深い鏡像関係を成している。Google Chromeの実装者らは、Windows上でセキュリティサンドボックスを実現するために、Windows XP SP2の実装に 深く依存せざるを得なかった 。市場を独占するOSのAPIや実装を管理できるというリソースを持ち合わせるMicrosoftにとっては、そのあたりの苦労は、技術的なものではなく、単に手続き的なもので...