Return-Path: 
 <dev-return-13539-apmail-synapse-dev-archive=synapse.apache.org@synapse.apache.org>
Delivered-To: apmail-synapse-dev-archive@www.apache.org
Received: (qmail 195 invoked from network); 6 Feb 2011 11:53:25 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3)
  by minotaur.apache.org with SMTP; 6 Feb 2011 11:53:25 -0000
Received: (qmail 75691 invoked by uid 500); 6 Feb 2011 11:53:24 -0000
Delivered-To: apmail-synapse-dev-archive@synapse.apache.org
Received: (qmail 75513 invoked by uid 500); 6 Feb 2011 11:53:21 -0000
Mailing-List: contact dev-help@synapse.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@synapse.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@synapse.apache.org>
List-Post: <mailto:dev@synapse.apache.org>
List-Id: <dev.synapse.apache.org>
Reply-To: dev@synapse.apache.org
Delivered-To: mailing list dev@synapse.apache.org
Received: (qmail 75506 invoked by uid 99); 6 Feb 2011 11:53:20 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 06 Feb 2011 11:53:20 +0000
X-ASF-Spam-Status: No, hits=1.5 required=5.0
	tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of indika.kuma@gmail.com
 designates 209.85.161.42 as permitted sender)
Received: from [209.85.161.42] (HELO mail-fx0-f42.google.com) (209.85.161.42)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 06 Feb 2011 11:53:12 +0000
Received: by fxm11 with SMTP id 11so5381092fxm.15
        for <dev@synapse.apache.org>; Sun, 06 Feb 2011 03:52:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:mime-version:in-reply-to:references:date
         :message-id:subject:from:to:content-type;
        bh=bdDSPjvVde2k6e1bV1ko/ttCJ6tw9N0+BQQcyouQWi0=;
        b=askZzt4EpspqVn8egX7KA5XotNivzFqo1t382zqdPEtb9SsMGGALLdSKVV7fbqgr1I
         Lc8tVXbiNTEtMpt5dpTVmmmek6HsIBBopcmQbCIJGr+8PXJMs9E6AFVQimY85fsu2Zbq
         JwQbAv5k90O/ivEIkbVmFdmm2Vg16B0PZ10Dc=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=fYDAAx8U1Yu+4DDqDXEreRyLV7lHdWIyLPNt6Jd4ALEgTerdi+H2wZuTR1lWmrrog2
         SrUTe/7YRxw//x5r392HBO7NPqMaIHKXDdAayP0cG0g/qfRGBFuADgtUn6kTnF/oQ5yy
         lNSA4gq71o9OEURcErQ56zNjNCogavlZfzE3s=
MIME-Version: 1.0
Received: by 10.223.96.206 with SMTP id i14mr6284778fan.67.1296993171826; Sun,
 06 Feb 2011 03:52:51 -0800 (PST)
Received: by 10.223.97.4 with HTTP; Sun, 6 Feb 2011 03:52:51 -0800 (PST)
In-Reply-To: <AANLkTimJZ_fWmshXMGY0x6XPiKWe0jQLxPk9ou1tTU9d@mail.gmail.com>
References: <AANLkTinEec1D=TtpaZvSU0Y4VRD+05GaksP2129uYWYj@mail.gmail.com>
	<AANLkTinQ0X9Loih-EeeCxPvk0LJkppX83dW7=G05LpTc@mail.gmail.com>
	<AANLkTikPY6Qz+SxUQ1NNHzNcca9Udf29hiKmC--3HsYT@mail.gmail.com>
	<AANLkTimyCt2_aa7D+3ooM89=Q1KKoiyn7U1kyktzW_dq@mail.gmail.com>
	<AANLkTimJZ_fWmshXMGY0x6XPiKWe0jQLxPk9ou1tTU9d@mail.gmail.com>
Date: Sun, 6 Feb 2011 17:52:51 +0600
Message-ID: <AANLkTime=OMGZTDORWiV64+ihafyAqOkP6iJKZYU941s@mail.gmail.com>
Subject: Re: Issue with switch on/off LoadBalance and FailOver endpoints from
 Jconsole
From: indika kumara <indika.kuma@gmail.com>
To: dev@synapse.apache.org
Content-Type: multipart/alternative; boundary=20cf30433ed24867f5049b9bc1f4
X-Virus-Checked: Checked by ClamAV on apache.org

--20cf30433ed24867f5049b9bc1f4
Content-Type: text/plain; charset=ISO-8859-1

Just another personal thought. Supporting parametrization as a first class
capability. I found XSLT 'template' and 'xsl:with-param' very interesting.
Endpoint definition, sequence definition, proxy definition. etc are kinds of
templates and not the concrete ones.  Calling such a template, the
corresponding language construct is created.

E.g.

<endpoint name="foo">
details ( There may be a URl or not)
</endpoint>

Creating an endpoint

<endpoint name="foo"/>
  <param name="url">value</param> // this is optional.
</endpoint>

URI is just one thing.  I am seeing an opportunity for a maximum reuse of
all language constructs. The use of  the template concept is very popular in
many languages.

BTW, I have not validated what I had said. All things are just based on my
intuition. So, these ideas may seem nonsense. if so, I am extremely sorry.

Thanks,

Indika

--20cf30433ed24867f5049b9bc1f4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Just another personal thought. Supporting parametrization as a first class =
capability. I found XSLT &#39;template&#39; and &#39;xsl:with-param&#39; ve=
ry interesting. Endpoint definition, sequence definition, proxy definition.=
 etc are kinds of templates and not the concrete ones.=A0 Calling such a te=
mplate, the corresponding language construct is created.<br>
<br>E.g. <br><br>&lt;endpoint name=3D&quot;foo&quot;&gt;<br>details ( There=
 may be a URl or not)<br>&lt;/endpoint&gt; <br><br>Creating an endpoint<br>=
<br>&lt;endpoint name=3D&quot;foo&quot;/&gt;<br>=A0 &lt;param name=3D&quot;=
url&quot;&gt;value&lt;/param&gt; // this is optional.<br>
&lt;/endpoint&gt;<br><br>URI is just one thing.=A0 I am seeing an opportuni=
ty for a maximum reuse of all language constructs. The use of=A0 the templa=
te concept is very popular in many languages. <br><br>BTW, I have not valid=
ated what I had said. All things are just based on my intuition. So, these =
ideas may seem nonsense. if so, I am extremely sorry.<br>
<br>Thanks,<br><br>Indika=A0 <br>

--20cf30433ed24867f5049b9bc1f4--