手作業で Slonik を書くことは、特に増加し続けるノードとセットの構成要素と妥協せざるを得ない Slony-I クラスタで作業を始めた限り、ある程度の苦痛を伴います。以下を含んだいくつかの問題が判っています。
もし 1 つの "マスター"ノードと 1 つの"スレーブ"ノードを持った"マスター/スレーブ"レプリケーションシステムとして Slony-I を使用するのであれば、"マスター" ノード 1 および "スレーブ" ノード 2 と簡略記号で呼んでも良いでしょう。
残念ながら、ノードに構成要素が増えるに従い、ノードに対する ID のマッピングは、特にオリジンがノードからノードへ刻々と変わるクラスタである時、より明確さの欠けた経路になります。
同様に、たった 1 つのレプリケーションセットがある場合は、"セット 1" で問題ないのですが、複数のセットがある場合、セット番号を用いた番号付けは直感的な理解が難しくなって行きます。
Slonik は如何なるプログラム命令の反復概念を提供していないことを見てきました。殆どの場合、ホストは特定のサーバに同一のホスト名、もしくは IP アドレスでアクセスするので、 STORE PATH エントリに似通ったセットを作成したいと思うのは一般的です。
利用者は TRY ブロック内に全ての可能なものをラップすることに興味があるようすが、これは残念ながら思ったよりも便利ではありません。
以下のような機能強化に対する要求に取り合わせて要約されます。
名前の付いたノードと名前の付いたセット
ループ計算と制御生成子
もうひとつの簡略言語が段々複雑な物に成長するので、本格的なパーサを作成する意味は余り無いように見られます。Slonik スクリプトを構築するのに使用できるスクリプト言語は数多くあります。別の言語の使用を強制するのは魅力的ではありません。
"世の中で"見られて来た、これら問題点に対処するいくつかの方法があります。
シェルスクリプト内に slonik 生成の埋め込み
src/ducttape ディレクトリにあるテストベッドはこの手法を採っています。
項18 は Slonik スクリプトの生成に Perl コードを使用します。
クラスタを Perl オブジェクトの集合として定義します。それぞれのスクリプトは、何であろうとも行うべき事を満足させる必要に応じ、Perl オブジェクトをウォークスルーします。