Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-dev@ws.apache.org
Received-SPF: pass (hermes.apache.org: domain of ajith.ranabahu@gmail.com
 designates 64.233.170.195 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references;
        b=TEg767UFV7J9w+VxLPR/WR8uNkCmpDnjRumJUMRRR085UWh9G39o1+zURsmd8PIbUB/D7Nk7FSDOp0YJnrn4dEeth3LtFjyBfZKFzNhVfqsPlL6/bcDhlUzvxGIhYjIR74hATODngykdVlpl2ZVvLZiWeW2AR/6aOqpTGpwturw=
Message-ID: <f43ea5790410212056da8c9d@mail.gmail.com>
Date: Fri, 22 Oct 2004 09:56:58 +0600
From: Ajith Ranabahu <ajith.ranabahu@gmail.com>
Reply-To: Ajith Ranabahu <ajith.ranabahu@gmail.com>
To: axis-dev@ws.apache.org, chintaka@opensource.lk
Subject: Re: use of immutable value object/interfaces [Re: [Axis2] OM API
 review/changes
In-Reply-To: <8737606755875833662@unknownmsgid>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
References: <417850F7.4030005@cs.indiana.edu>
	 <8737606755875833662@unknownmsgid>

Hi,
How I see this mutable/immutable thing is this.
If we make an object immutable we are done with making changes to it.
The only option we have if we are not happy with the values that are
inside the immutable object is to make a new one with the correct
values and replace the earlier one.
As far as an XML document structure is concerned, having to create a
whole new element when a change is needed seems ridiculous (since it
is quite frequent). by contrast namespaces stay unchanged through the
scope of the document and are good candidates for being immutable
objects.
Hopefully this is the essence of the concept of mutable/immutable.
Please correct me if I am wrong.
When our OM is concerned, I tend to put only OMNamespace as immutable.
An attribute doesn't seems to be that much convincing as an immutable
object to me.

Ajith
>On Fri, 22 Oct 2004 09:27:24 +0600, Eran Chinthaka
><chintaka@opensource.lk> wrote:
>=20
>=20
>=20
> Alek's idea of making OMElement mutable and others immutable seems
> interesting.=20
>=20
> =20
>=20
> Shall we talk about this in use cases perpectives ???
>=20
> =20
>=20
> What are the things we do for the soap message within the engine ??
>=20
> =20
>=20
> 1.    need to access the headers. What we basically do here is that mostl=
y
> read the contents of the headers. And sometime may remove and add new
> headers. Plus we may modify Element, Texts, Attributes. But I think we
> rarely do modifications to comments or namespaces. In this regard, making
> OMElement mutable make sense, but I would say that Attributes are highly
> subjected to modifications. So making OMAttributes also mutable seems goo=
d.
> But I agree in making rest of the things immutable.
>=20
> 2.    If u think about the body, in current situations this will be acces=
sed
> only by either Security handlers or by the provider. (If this is not
> correct, I like to see a *use case*, where someone need to access the bod=
y).
> Provider of course, it needs to just read the contents of the body. SO th=
ere
> are no modifications to the body.
>=20
> As Sanjiva said, we can forget the performance discussion about the
> supporting of security.=20
>=20
> =20
>=20
> So in conclusion, I think following seems to be ok, for the time being.
>=20
> =20
>=20
> OMElement, OMAttribute =E2=80=93 mutable
>=20
> OMNamespace, OMText (or String) =E2=80=93 immutable.
>=20
> =20
>=20
> Plus I also agree with the idea of "to allow use of immutable objects tha=
t
> can be shared (such as the same namespace) between multiple elements lead=
ing
> to lower memory usage."
>=20
> =20
>=20
> =20
>=20
> Comments =E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6 ?=20
>=20
> =20
>=20
> ________________________________
>=20
> =20
>=20
> Eran Chinthaka
>=20
> Lanka Software Foundation
>=20
>=20
>=20
> =20
>=20
> > -----Original Message-----
>=20
> > From: Aleksander Slominski [mailto:aslom@cs.indiana.edu]
>=20
> > Sent: Friday, October 22, 2004 6:15 AM
>=20
> > To: axis-dev@ws.apache.org
>=20
> > Cc: chintaka@opensource.lk
>=20
> > Subject: use of immutable value object/interfaces [Re: [Axis2] OM API
>=20
> > review/changes
>=20
> >=20
>=20
> > Sanjiva Weerawarana wrote:
>=20
> >=20
>=20
> > >"Aleksander Slominski" <aslom@cs.indiana.edu> writes:
>=20
> > >
>=20
> > >
>=20
> > >>i agree that API should be easy to use but we need to strive for a
>=20
> > >>balance and be careful to have necessary methods to make API easy to
>=20
> > >>use  (but not too many) and to allow use of immutable objects that ca=
n
>=20
> > >>be shared (such as the same namespace) between multiple elements lead=
ing
>=20
> > >>to lower memory usage.
>=20
> > >>
>=20
> > >>
>=20
> > >
>=20
> > >I'm confused .. we obviously need to create the OM too. Are we
>=20
> > >talking about disallowing one to *modify* an already created tree
>=20
> > >instead of about having methods to create a new OM?
>=20
> > >
>=20
> > >
>=20
> > no that is nto what i meant.
>=20
> >=20
>=20
> > i though about case of tree (OMElement) that is container of objects
>=20
> > where some of those objects are immutable (like namespaces or attribute=
s).
>=20
> > so if you need to change element namespace or attribute just create new
>=20
> > one and replace element namespace or attribute.
>=20
> >=20
>=20
> > exactly the same reasoning goes for immutability of String (including
>=20
> > multi-thread safety for sharing, caching, low memory usage etc.) and fo=
r
>=20
> > more detailed rationale for immutable "value" object please read (bette=
r
>=20
> > explained that i can):
>=20
> > http://www-106.ibm.com/developerworks/java/library/j-jtp02183.html
>=20
> >=20
>=20
> > >If so I'm ok with having the OM be immutable at least initially.
>=20
> > >
>=20
> > >
>=20
> > i was not proposing anyting that radical - i think OMElement should be
>=20
> > mutable only OMNamespace, OMAttribute should be immutable (and maybe
>=20
> > OMComment).
>=20
> >=20
>=20
> > >That should give us maximum performance and if you really want
>=20
> > >to modify the OM then you have to re-generate it. That may bite
>=20
> > >us badly when dealing with encrypted headers but we can delay
>=20
> > >that a bit I think. (Decryption will be so slow that creating
>=20
> > >a new OM will not be a problem :)) However, we should be able
>=20
> > >to re-parent OM nodes I think.
>=20
> > >
>=20
> > >
>=20
> > that would be interesting: to have read-only API, copy-on-write API and
>=20
> > full read-write API subsets that are selectable as required by and
>=20
> > described in metadata of handlers ...
>=20
> >=20
>=20
> > thanks,
>=20
> >=20
>=20
> > alek
>=20
> >=20
>=20
> > --
>=20
> > The best way to predict the future is to invent it - Alan Kay
>=20
> >=20
>=20
> =20


--=20
Ajith Ranabahu