Mailing-List: contact dev-help@synapse.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@synapse.apache.org
Received-SPF: pass (nike.apache.org: domain of indika.kuma@gmail.com
 designates 74.125.83.170 as permitted sender)
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=rEQRLg2VsChk67GG7dN2NNfn9b8nvqole261U8X6ND/BGpIVpFt7inabnhBgdNaXG8
         4oiLQ4+aBkFxE/ZGe/+fOysSzoUCOOlqM+D8sH72jPg9uHwtTmgfLDnBw+GgMPJwXlE2
         N9+nGsXlDDyTWpVfVSJYBo/ScHJ5HN+wI/G+4=
MIME-Version: 1.0
In-Reply-To: <j2z558af1841005040527i76be30a1gb2e86eb8bfcf8eef@mail.gmail.com>
References: <p2y558af1841005040523ncae4ebcr228936e6ce880139@mail.gmail.com>
	 <j2z558af1841005040527i76be30a1gb2e86eb8bfcf8eef@mail.gmail.com>
Date: Tue, 4 May 2010 22:25:10 +0600
Message-ID: <l2rd173c15d1005040925i5f78ca96p674695b2683a91c2@mail.gmail.com>
Subject: Re: Generating Names for Anon. Endpoints
From: indika kumara <indika.kuma@gmail.com>
To: dev@synapse.apache.org
Content-Type: multipart/alternative; boundary=00221540001242d78a0485c727a5

--00221540001242d78a0485c727a5
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

>
> What makes you think the current approach for endpoints is 'incorrect'? I=
f
> it is not correct then that indeed is a problem we should get fixed
>

Hiranja

As currently, we generate a random one (so unique), therefore the internal
operation is correct as far as users do not specify a name. However, as
users also specified names if we do not validate names, we cannot grantee
the uniqueness. (As per my knowledge, we do not validate names for in-lined
endpoints... I did not check code =85 so... I may be wrong)=85 Therefore, t=
here
is a possibility for incorrect operation.

On the other hand, the generated name does not represent any context
information such as for what  this endpoint is (The =91server1.foo=92 the
endpoint for the service =91foo=92 in the server 1). We cannot generate suc=
h a
meaningful name=85

On the other hand, in synapse even if you have generated internally a name
for an endpoint, the end user does not know it. There is no tool for viewin=
g
names of endpoints. Then the name will become another internal thing that
uses for the correct operation of endpoints and from the user perspective,
he cannot easily use it for diagnosing any errors, JMS monitoring, etc.
(Currently, Name is not for users but for our internal working).  A named
entity is used by a user to separate a particular entity from others
entities in both configurations and runtime data.  In synapse, Statistics
(JMX) is one =85 JMS monitoring is another, error log analyzing is another
one=85 However, the clustering is not. It is an internal operation.  For su=
ch
an internal operation, generating a name or id is perfectly OK as it is not
for users.    Name is for users =85. Internally generated ID is for interna=
l
operations.

That is why I would like, at least for any operations that require an
endpoint name, to warn (at latest) users if there is no name has been
specified.

Making the name mandatory will be too good as it brings more advantages for
users than disadvantages.

A user will only recognize the importance of a context aware meaningful
name, when things go wrong and he need to identify the error based on the
information in the logs. =85If it was a very random issue and cannot be eas=
ily
reproduced, what kind of feeling will he feel? =85 I believe, after that da=
y,
we will put names carefully =96 not just a unique name but meaningful =85

Thanks
Indika

--00221540001242d78a0485c727a5
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"borde=
r-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-le=
ft: 1ex;"><div class=3D"gmail_quote"><div>What makes you think the current =
approach for endpoints is &#39;incorrect&#39;? If it is not correct then th=
at indeed is a problem we should get fixed</div>
</div></blockquote><div><br>Hiranja <br></div></div><br>As currently, we ge=
nerate a random one (so unique), therefore the internal operation is correc=
t as far as users do not specify a name. However, as users also specified n=
ames if we do not validate names, we cannot grantee the uniqueness. (As per=
 my knowledge, we do not validate names for in-lined endpoints... I did not=
 check code =85 so... I may be wrong)=85 Therefore, there is a possibility =
for incorrect operation.=A0 <br>
<br>On the other hand, the generated name does not represent any context in=
formation such as for what=A0 this endpoint is (The =91server1.foo=92 the e=
ndpoint for the service =91foo=92 in the server 1). We cannot generate such=
 a meaningful name=85=A0 <br>
<br>On the other hand, in synapse even if you have generated internally a n=
ame for an endpoint, the end user does not know it. There is no tool for vi=
ewing names of endpoints. Then the name will become another internal thing =
that uses for the correct operation of endpoints and from the user perspect=
ive, he cannot easily use it for diagnosing any errors, JMS monitoring, etc=
. (Currently, Name is not for users but for our internal working).=A0 A nam=
ed entity is used by a user to separate a particular entity from others ent=
ities in both configurations and runtime data.=A0 In synapse, Statistics (J=
MX) is one =85 JMS monitoring is another, error log analyzing is another on=
e=85 However, the clustering is not. It is an internal operation.=A0 For su=
ch an internal operation, generating a name or id is perfectly OK as it is =
not for users.=A0=A0=A0 Name is for users =85. Internally generated ID is f=
or internal operations. <br>
<br>That is why I would like, at least for any operations that require an e=
ndpoint name, to warn (at latest) users if there is no name has been specif=
ied. <br><br>Making the name mandatory will be too good as it brings more a=
dvantages for users than disadvantages. <br>
<br>A user will only recognize the importance of a context aware meaningful=
 name, when things go wrong and he need to identify the error based on the =
information in the logs. =85If it was a very random issue and cannot be eas=
ily reproduced, what kind of feeling will he feel? =85 I believe, after tha=
t day, we will put names carefully =96 not just a unique name but meaningfu=
l =85 <br>
<br>Thanks <br>Indika <br>=A0 <br><br>

--00221540001242d78a0485c727a5--