X-Original-To: alpine-devel@lists.alpinelinux.org
Delivered-To: alpine-devel@mail.alpinelinux.org
Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54])
	(using TLSv1 with cipher RC4-SHA (128/128 bits))
	(No client certificate requested)
	by mail.alpinelinux.org (Postfix) with ESMTPS id 7AB18DC0EC9
	for <alpine-devel@lists.alpinelinux.org>; Mon,  2 Jan 2012 09:16:23 +0000 (UTC)
Received: by lahl5 with SMTP id l5so8249591lah.13
        for <alpine-devel@lists.alpinelinux.org>; Mon, 02 Jan 2012 01:16:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=sender:message-id:date:from:user-agent:mime-version:to:subject
         :references:in-reply-to:x-enigmail-version:content-type
         :content-transfer-encoding;
        bh=5LjsAjdcWONPIuceqt3/rBHThQQPAbEPp102dAfa2Is=;
        b=p19E+Y5f4zFqmdRIbT860RpSeg8KfCeYm+Dqzane8dlw2R0HJcW2pXT0jIeZnTQJfF
         05dN3du0mY7fJUX7HFDjSYpaDL2sT2AEMuoAqyTR9hlzZ2NjWoE1GlpDqP83Vckrf0FA
         wELx1u4INoarjckkrIRPMRcE2o89BKwLon8iU=
Received: by 10.152.111.136 with SMTP id ii8mr38273628lab.20.1325495780457;
        Mon, 02 Jan 2012 01:16:20 -0800 (PST)
Received: from [192.168.1.34] (l193.ip7.netikka.fi. [85.157.167.193])
        by mx.google.com with ESMTPS id nu4sm39132236lab.4.2012.01.02.01.16.19
        (version=TLSv1/SSLv3 cipher=OTHER);
        Mon, 02 Jan 2012 01:16:19 -0800 (PST)
Sender: =?UTF-8?Q?Timo_Ter=C3=A4s?= <timo.teras@gmail.com>
Message-ID: <4F0175E2.7020603@iki.fi>
Date: Mon, 02 Jan 2012 11:16:18 +0200
From: =?ISO-8859-1?Q?Timo_Ter=E4s?= <timo.teras@iki.fi>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0) Gecko/20111223 Thunderbird/10.0
X-Mailinglist: alpine-devel
Precedence: list
List-Id: Alpine Development <alpine-devel.lists.alpinelinux.org>
List-Unsubscribe: 
	<mailto:alpine-devel+unsubscribe@lists.alpinelinux.org?subject=unsubscribe>
List-Post: <mailto:alpine-devel@lists.alpinelinux.org>
List-Help: <mailto:alpine-devel+help@lists.alpinelinux.org?subject=help>
List-Subscribe: 
	<mailto:alpine-devel+subscribe@lists.alpinelinux.org?subject=subscribe>
MIME-Version: 1.0
To: alpine-devel@lists.alpinelinux.org
Subject: Re: [alpine-devel] Alpine Wall for firewall management
References: <alpine.LFD.2.02.1112301354560.21584@kunkku.net> <4EFE2E41.30809@alpinelinux.org>
In-Reply-To: <4EFE2E41.30809@alpinelinux.org>
X-Enigmail-Version: 1.3.4
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On 12/30/2011 11:33 PM, Nathan Angelacos wrote:
> On 12/30/2011 06:08 AM, Kaarle Ritvanen wrote:
>> We have a new firewall management framework under early development.
>> Please check out the draft specification here and provide your comments:
>>
>> http://wiki.alpinelinux.org/wiki/Alpine_Wall
> 
> Nice write-up!  Thanks!   This looks promising.
> 
> <phb>
> Interesting name choice too.  Its functional description almost exactly
> matches http://en.wikipedia.org/wiki/Alpine_Wall
> </phb>

+1 from here too.

The discussion I'd like to have is if the "new template language" or
"Lua framework" would be used internally. I don't have strong opinion
either way. I would probably personally go with the framework approach,
but that's just because I'm more familiar with that kind of things.

I'm trying to list pros and cons, so please feel free to add thoughts.

New DSL (Domain Specific Language):
 + fast to write simple functionality
 + template is probably shorter than corresponding framework code
 - might need additional framework support for complex things
 - requires learning and definition of a new language
 - one needs to do template for each target "language"
   (iptables-save file format would be enough)

Purely Framework:
 + complex policies and transformations doable programmatically
 + familiar programming language
 - new framework API needs learning
 - might need internal representations of firewall rules, adding
   to work (but adding additional target formats easier)

Also, my guess is that new language + compiler for it is slower. Though
the differences would be fraction of second class for the common case.

So to me it sounds like both are viable choices. And ultimately it'll
probably be left as implementator's choice.

Cheers,
 Timo


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---