axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aleksander Slominski <as...@cs.indiana.edu>
Subject Re: use of immutable value object/interfaces [Re: [Axis2] OM API review/changes
Date Fri, 22 Oct 2004 04:22:13 GMT
Eran Chinthaka wrote:

> 2. If u think about the body, in current situations this will be 
> accessed 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 body).
>
security and RM are main suspects that will need to 
access/transform/store whole Envelope including Body.

> Provider of course, it needs to just read the contents of the body. SO 
> there are no modifications to the body.
>
> As Sanjiva said, we can forget the performance discussion about the 
> supporting of security.
>
i would look on it differently: we know it is slow but we try to avoid 
introducing overheads and try not to make it *too* slow or taking *too* 
much memory ...

> So in conclusion, I think following seems to be ok, for the time being.
>
AFAICT most (all?) attributes will be be read-only (when parsing 
incoming message) and write-only/generate-once when generating output?

if OMAttribute is immutable (so called value object) then once created 
the attribute can be shared safely and used when generating output in 
*multiple* threads! i think it is big gain when we have to generate 
again and again very similar looking SOAP messages ...

> OMElement, OMAttribute – mutable
>
> OMNamespace, OMText (or String) – immutable.
>
> Plus I also agree with the idea of “to allow use of immutable objects 
> that can be shared (such as the same namespace) between multiple 
> elements leading to lower memory usage.”
>
> Comments …………… ?
>
what are the cases that you need to modify existing attribute?! like 
change its name (better to create new attribute) or value (why not get 
value right when you create attribute)?

thanks,

alek

>> -----Original Message-----
>
>> From: Aleksander Slominski [mailto:aslom@cs.indiana.edu]
>
>> Sent: Friday, October 22, 2004 6:15 AM
>
>> To: axis-dev@ws.apache.org
>
>> Cc: chintaka@opensource.lk
>
>> Subject: use of immutable value object/interfaces [Re: [Axis2] OM API
>
>> review/changes
>
>>
>
>> Sanjiva Weerawarana wrote:
>
>>
>
>> >"Aleksander Slominski" <aslom@cs.indiana.edu> writes:
>
>> >
>
>> >
>
>> >>i agree that API should be easy to use but we need to strive for a
>
>> >>balance and be careful to have necessary methods to make API easy to
>
>> >>use (but not too many) and to allow use of immutable objects that can
>
>> >>be shared (such as the same namespace) between multiple elements 
> leading
>
>> >>to lower memory usage.
>
>> >>
>
>> >>
>
>> >
>
>> >I'm confused .. we obviously need to create the OM too. Are we
>
>> >talking about disallowing one to *modify* an already created tree
>
>> >instead of about having methods to create a new OM?
>
>> >
>
>> >
>
>> no that is nto what i meant.
>
>>
>
>> i though about case of tree (OMElement) that is container of objects
>
>> where some of those objects are immutable (like namespaces or 
> attributes).
>
>> so if you need to change element namespace or attribute just create new
>
>> one and replace element namespace or attribute.
>
>>
>
>> exactly the same reasoning goes for immutability of String (including
>
>> multi-thread safety for sharing, caching, low memory usage etc.) and for
>
>> more detailed rationale for immutable "value" object please read (better
>
>> explained that i can):
>
>> http://www-106.ibm.com/developerworks/java/library/j-jtp02183.html
>
>>
>
>> >If so I'm ok with having the OM be immutable at least initially.
>
>> >
>
>> >
>
>> i was not proposing anyting that radical - i think OMElement should be
>
>> mutable only OMNamespace, OMAttribute should be immutable (and maybe
>
>> OMComment).
>
>>
>
>> >That should give us maximum performance and if you really want
>
>> >to modify the OM then you have to re-generate it. That may bite
>
>> >us badly when dealing with encrypted headers but we can delay
>
>> >that a bit I think. (Decryption will be so slow that creating
>
>> >a new OM will not be a problem :)) However, we should be able
>
>> >to re-parent OM nodes I think.
>
>> >
>
>> >
>
>> that would be interesting: to have read-only API, copy-on-write API and
>
>> full read-write API subsets that are selectable as required by and
>
>> described in metadata of handlers ...
>
>>
>
>> thanks,
>
>>
>
>> alek
>
>>
>
>> --
>
>> The best way to predict the future is to invent it - Alan Kay
>
>>
>


-- 
The best way to predict the future is to invent it - Alan Kay


Mime
View raw message