axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ajith Ranabahu <ajith.ranab...@gmail.com>
Subject Re: [Axis2] IRC chat log 2004-09-15
Date Thu, 16 Sep 2004 03:08:04 GMT
Here is the part that Alek missed :)

[20:25]<alek-leaving> bye
[20:25]  *** alek-leaving quit FreeNode : "Chatzilla 0.9.64g [Mozilla
rv:1.7.3/20040911]"
[20:25]  *** Jochen joined #apache-axis
[20:25]  *** as10m quit FreeNode : "Miranda IM! Smaller, Faster,
Easier. http://miranda-im.org"
[20:25]<Srinath> hi jochen
[20:26]<Jochen> Hi. First time on IRC since about 1995. :-)
[20:26]<Srinath> :)
[20:26]<Srinath> we talk lot about OM ...
[20:26]<Srinath> you can find from the chat log
[20:27]<Jochen> It is quite possible, that we have different concerns.
[20:27]<Jochen> My understanding is, that you are talking about the OM
you will typically use.
[20:28]<Srinath> I am positive we do not recreate the performance prob with OM
[20:28]<Jochen> If you *force* using the OM (as proposed by Alek), I
am sure you wil, at least for large documents.
[20:29]<Srinath> IFF only you accsess the body
[20:29]<Srinath> but  in that case it is facts of life
[20:29]<Jochen> Yes, but isn't the body what it is all for. :-)
[20:30]<Srinath> IFF body is accessed by handelrs (sorry I miss interpret)
[20:30]<Srinath> not the provider
[20:30]<Srinath> :)
[20:30]<Srinath> providers will not cache any thing
[20:31]<Jochen> Yes, but why distinguish between body and header, if
it aint necessary?
[20:31]<Srinath> becouse usually headers are small..
[20:31]<Srinath> body is not
[20:32]<Deepal> Srinath that is not teh case all the time
[20:32]<Srinath> we got to read all the header to the memeory ..no
matter what you do
[20:32]<Srinath> SOAP processing model require it
[20:32]<Srinath> e.g. mustunderstnd attribute
[20:33]<Jochen> Well, I can agree on that. Fix me if I am wrong: Does
the OM apply to the body (at least for the outmost element) or not?
[20:33]<Srinath> yes
[20:33]<Srinath> but at the provider the cache set off ..
[20:33]<Srinath> then om will not cache anything
[20:34]<Srinath> but read and provide pull events
[20:34]<Srinath> body will not kept in the memeory
[20:34]<Deepal> bt i remember we can cache off for header too , am i correct ?
[20:34]<Jochen> What would the provider do? Convert the events into OM or nor?
[20:35]<Srinath> when cache set off .. nothing will be caches
[20:35]<Srinath> OM has a pull API as well
[20:36]<Srinath> that do not cache if it cahce is off
[20:36]<Srinath> BTW We got to go 
[20:36]<Deepal> yes Srinath
[20:36]<dasarathw> yep
[20:36]<Deepal> now 8.40 pm at SL
[20:36]<dasarathw> so prototypes till next week!
[20:36]<dasarathw> cy
[20:36]<Srinath> jochen pls join us next week same time 
[20:36]<Ajith4102> hunger strikes :)
[20:37]<Srinath> :)
[20:37]  *** dasarathw quit FreeNode : 
[20:37]<Srinath> me too
[20:37]<sanjiva_> bye guys .. let's try to make sure that we cut off @
8pm next time .. not fair to make u guys be so late for dinner! good
nite ...
[20:37]<Srinath> :) good nite
[20:37]<Deepal> mo sir its not too late
[20:37]<Deepal> :)
[20:37]<Srinath> deepal pls chat bit more
[20:37]<Srinath> :)
[20:38]<Ajith4102> he he
[20:38]<Ajith4102> byee guys
[20:38]<Jochen> Bye!


On Wed, 15 Sep 2004 12:28:15 -0500, Aleksander Slominski
<aslom@cs.indiana.edu> wrote:
> as promised i am sending IRC chat log.
> 
> i missed the end of chat as it went well past an hour
> as it was good discussion about OM requirements, use cases,
> performance vs DOM, support for whites paces and how much XML
> infoset is needed, how to deal with options, and next steps
> 
> thanks,
> 
> alek
> 
> [9/15/2004 8:06 AM] <alek_s> i turned on logging and i can post log
> [9/15/2004 8:07 AM] <Srinath> cool I got it on as well :)
> [9/15/2004 8:07 AM] <Srinath> let us discuss OM .. Paul shall we
> [9/15/2004 8:08 AM] -->| Ajith4102 (~Miranda@220.247.230.25) has joined #apache-axis
> [9/15/2004 8:08 AM] <Ajith4102> finally
> [9/15/2004 8:08 AM] <Ajith4102> I got disconnected suddenly
> [9/15/2004 8:08 AM] <chathura> :)
> [9/15/2004 8:09 AM] <Ajith4102> we seem to have some probs with trhe nerwork here
> [9/15/2004 8:09 AM] <Srinath> Ajith has send few comments on the Alex's interface
> [9/15/2004 8:10 AM] |<-- Ajith has left irc.freenode.net (Read error: 110 (Connection
timed out))
> [9/15/2004 8:11 AM] <Ajith4102> deepal and dasarath still has problems connecting
> [9/15/2004 8:11 AM] |<-- Deepal has left irc.freenode.net (Read error: 110 (Connection
timed out))
> [9/15/2004 8:12 AM] -->| dasarathw (~dasarath@220.247.230.25) has joined #apache-axis
> [9/15/2004 8:12 AM] |<-- dasarath has left irc.freenode.net (Read error: 110 (Connection
timed out))
> [9/15/2004 8:12 AM] <dasarathw> at LSF we are having some trouble connecting:(
> [9/15/2004 8:14 AM] <Srinath> to bussnuiss :) OM
> [9/15/2004 8:14 AM] <Ajith4102> yep
> [9/15/2004 8:14 AM] -->| sanjiva (~sanjiva@199.43.208.168) has joined #apache-axis
> [9/15/2004 8:15 AM] <sanjiva> hi guys
> [9/15/2004 8:15 AM] <sanjiva> sorry I'm late
> [9/15/2004 8:15 AM] <Ajith4102> Seems all are again connected
> [9/15/2004 8:15 AM] <Ajith4102> hi
> [9/15/2004 8:15 AM] <chathura> hi
> [9/15/2004 8:15 AM] <Ajith4102> no prob
> [9/15/2004 8:15 AM] <dasarathw> hi
> [9/15/2004 8:15 AM] <Ajith4102> we just started
> [9/15/2004 8:15 AM] <Chinthaka> shall we start with OM ?
> [9/15/2004 8:15 AM] <dasarathw> hope things remain that way
> [9/15/2004 8:15 AM] <Ajith4102> sure
> [9/15/2004 8:16 AM] <Ajith4102> A simple set of iterfaces are at the SVN
> [9/15/2004 8:16 AM] -->| Deepal (~deepal@220.247.230.25) has joined #apache-axis
> [9/15/2004 8:16 AM] <alek_s> how does proposed plan of action look? at http://wiki.apache.org/ws/FrontPage/Architecture/OM
> [9/15/2004 8:17 AM] <Chinthaka> do we need to implement the whole XML infoset ?
> [9/15/2004 8:17 AM] <Chinthaka> as stated in the wiki page ?
> [9/15/2004 8:17 AM] <alek_s> i think as minimum we need what is required for SOAP
> [9/15/2004 8:18 AM] <Chinthaka> agreed
> [9/15/2004 8:18 AM] <Srinath> shall we start with the OM infoset interface Alek
publish
> [9/15/2004 8:18 AM] <Deepal> alex but then we cant support for DOM2/DOM3 etc
> [9/15/2004 8:19 AM] <alek_s> Ajith: please add link to your code in Current work
section in http://wiki.apache.org/ws/FrontPage/Architecture/OM
> [9/15/2004 8:19 AM] <alek_s> i think we have multiple choices how to support DOM
> [9/15/2004 8:20 AM] <Ajith4102> we actually srinath did the check in since I still
dont have rights
> [9/15/2004 8:20 AM] <Ajith4102> so I will tell him
> [9/15/2004 8:20 AM] <alek_s> however i am really concerned that we do not create
too heavyweight DOM
> [9/15/2004 8:20 AM] <Ajith4102> yep
> [9/15/2004 8:20 AM] <Deepal> i agreed
> [9/15/2004 8:21 AM] <alek_s> so if we have soemthing very lightweight for servivces
that do not require full DOM that should be good ...
> [9/15/2004 8:21 AM] -->| gdaniels (~gdaniels@psc.progress.com) has joined #apache-axis
> [9/15/2004 8:21 AM] <Chinthaka> yeah
> [9/15/2004 8:21 AM] <gdaniels> hi folks
> [9/15/2004 8:21 AM] <Chinthaka> hi glen
> [9/15/2004 8:21 AM] <dasarathw> hi glen
> [9/15/2004 8:21 AM] <Srinath> hi glen
> [9/15/2004 8:21 AM] <Deepal> hi glen
> [9/15/2004 8:22 AM] <gdaniels> (Sanjiva probably mentioned we're at a meeting in
Toronto, and probably can only tune in with about 25% brain :))
> [9/15/2004 8:22 AM] <sanjiva> we decided not to full DOM .. the idea was to do
enough to enable ws-sec to work on top of the OM directly. I'm even willing to say even that
can be layered because the ws-sec impl is (necessarily) so slow compared to wrapping a DOM
that it likely won't matter
> [9/15/2004 8:22 AM] <Ajith4102> alek : that is right. We need the simplest possible
> [9/15/2004 8:22 AM] <Srinath> yes it is DOM-
> [9/15/2004 8:22 AM] <Ajith4102> alek: the link is http://svn.apache.org/repos/asf/webservices/axis/trunk/java/dev/scratch/ajith_deepal_srinath/
> [9/15/2004 8:23 AM] <gdaniels> +1 simple, efficient
> [9/15/2004 8:23 AM] <gdaniels> full DOM is going to be a shim on top anyway, and
we just try to make that as thin as possible
> [9/15/2004 8:23 AM] <sanjiva> Or if we want to just use the DOM APIs that's fine
too but then stub out the impl of most of the unnecessary/stuff .. and allow a layer to impl
the rest
> [9/15/2004 8:23 AM] <sanjiva> Glen: +1
> [9/15/2004 8:24 AM] <Srinath> the methods like getSize() .. getChild() .. couse
problems
> [9/15/2004 8:24 AM] <alek_s> Ajith: i added link to svn code to wiki page
> [9/15/2004 8:24 AM] <gdaniels> Do we want the same kind of Node ancestor class
as DOM has?
> [9/15/2004 8:25 AM] <Srinath> do we?
> [9/15/2004 8:25 AM] <gdaniels> or do we just simplify and make Elements and Attributes
top-level
> [9/15/2004 8:25 AM] <alek_s> i think that would make OM very non lightweight ...
> [9/15/2004 8:25 AM] <Deepal> i agree with glen
> [9/15/2004 8:25 AM] <alek_s> i am for simplification
> [9/15/2004 8:26 AM] <Srinath> yes .. how about something very simple what Ajith
talking about ..
> [9/15/2004 8:26 AM] <alek_s> we will have Node ansector class anyway when we provide
DOM API impl
> [9/15/2004 8:27 AM] <Chinthaka> XML infoset talks about 11 types of information
items
> [9/15/2004 8:28 AM] <Chinthaka> if we adapt this to our requirements
> [9/15/2004 8:28 AM] <Srinath> shall we start with Aleks and Ajiths interfaces ..
and talk
> [9/15/2004 8:28 AM] <Srinath> else we might miss some parts
> [9/15/2004 8:29 AM] <Srinath> there is two interfaces and Aiths comments on them
> [9/15/2004 8:29 AM] <Deepal> Do we need to support all the eleven type of information
items ?
> [9/15/2004 8:29 AM] <Chinthaka> no
> [9/15/2004 8:29 AM] <Ajith4102> hopefully not !
> [9/15/2004 8:29 AM] <Deepal> I think for SOAP we dont need all
> [9/15/2004 8:29 AM] <Srinath> 1. Methods to create new objects (ex elements) like
DOM. Should we
> [9/15/2004 8:29 AM] <Srinath> have this functionality inside our OM as well?
> [9/15/2004 8:29 AM] <Srinath> 2. Do we need a class for namespace? For instance
the om element
> [9/15/2004 8:29 AM] <Srinath> interface has a prefix and a namespace name according
> [9/15/2004 8:29 AM] <Srinath> to the infoset spec. since we are doing a minimal
implementation,
> [9/15/2004 8:29 AM] <Srinath> doing this with just a String for now seems to be
ok.
> [9/15/2004 8:29 AM] <Chinthaka> I think if we look at Ajith's code
> [9/15/2004 8:29 AM] <Srinath> 3. Facilities to remove children and change them
are indeed useful.
> [9/15/2004 8:29 AM] <Srinath> 4. Providing Iterators (in place of any other data
structure like a
> [9/15/2004 8:29 AM] <Srinath> List) and defering the parsing is cool :)
> [9/15/2004 8:29 AM] <Srinath> 5. Should we provide two (or morel) ways to do the
same thing? For
> [9/15/2004 8:29 AM] <Chinthaka> what is required is abvious
> [9/15/2004 8:30 AM] <Srinath> example setting the attribute can be done in several
ways. Perhaps
> [9/15/2004 8:30 AM] <Srinath> this is just the ease of use but reducing such items
will reduce the
> [9/15/2004 8:30 AM] <Srinath> complexity at least in the initial stage.
> [9/15/2004 8:30 AM] <Srinath> I paste the Ajiths commets
> [9/15/2004 8:30 AM] <dasarathw> i don't think so
> [9/15/2004 8:30 AM] <dasarathw> i don't think so
> [9/15/2004 8:30 AM] <gdaniels> it's hard to deal with so many comments at once,
Srinath
> [9/15/2004 8:30 AM] <gdaniels> let's take them one at a time, perhaps?
> [9/15/2004 8:30 AM] <sanjiva> +1!
> [9/15/2004 8:30 AM] <Srinath> yap .. sorry :)
> [9/15/2004 8:30 AM] <Ajith4102> oops this is getting complicated. shall we take
one by one and discuss
> [9/15/2004 8:30 AM] <Srinath> sure
> [9/15/2004 8:30 AM] <Ajith4102> yep
> [9/15/2004 8:30 AM] <Deepal> yep Ajith
> [9/15/2004 8:31 AM] <dasarathw> +1
> [9/15/2004 8:31 AM] <Srinath> 1)Methods to create new objects (ex elements) like
DOM. Should we
> [9/15/2004 8:31 AM] <Srinath> have this functionality inside our OM as well?
> [9/15/2004 8:31 AM] <sanjiva> Can we start with the scope of OM?
> [9/15/2004 8:31 AM] <gdaniels> 1 - Clearly we need methods to create new elements,
but I've never liked the "factory" approach
> [9/15/2004 8:31 AM] <Deepal> yep
> [9/15/2004 8:31 AM] <sanjiva> It *has to* retain teh full infoset .. otherwise
canonicalization when computing signatures will break.
> [9/15/2004 8:31 AM] <sanjiva> Do we all agree?
> [9/15/2004 8:31 AM] <Srinath> let the contructors do it?
> [9/15/2004 8:31 AM] <gdaniels> I'd rather be able to say myOMElement.addChild(new
OMElement(namespace, localPart, javaObject))
> [9/15/2004 8:31 AM] <sanjiva> Does anyone know whether that means we have to retain
whitespace nodes too?
> [9/15/2004 8:32 AM] <dasarathw> full inforset?
> [9/15/2004 8:32 AM] <sanjiva> s/inforset/infoset/
> [9/15/2004 8:32 AM] <gdaniels> yes, full infoset
> [9/15/2004 8:32 AM] <Srinath> yes glen +1
> [9/15/2004 8:32 AM] <gdaniels> I think we do need to retain whitespace yes
> [9/15/2004 8:32 AM] <dasarathw> but do we need all those items for soap?
> [9/15/2004 8:32 AM] <gdaniels> yes
> [9/15/2004 8:32 AM] <sanjiva> For SOAP security to work, yes
> [9/15/2004 8:32 AM] <alek_s> i think so too
> [9/15/2004 8:32 AM] <Deepal> do we need all eleven ?
> [9/15/2004 8:32 AM] <gdaniels> and intermediaries
> [9/15/2004 8:32 AM] <Srinath> did white space matters in SOAP?
> [9/15/2004 8:32 AM] <gdaniels> yes white space matters sometimes
> [9/15/2004 8:33 AM] <sanjiva> Not in SOAP Srinath but for WS-Sec yes it matters!
If you add a space the signature is different
> [9/15/2004 8:33 AM] <sanjiva> (or something else; I don't know the security stuff
much)
> [9/15/2004 8:33 AM] <alek_s> as of facotry: i think we should use factories so
 we can configure OM builder to create OM with oir without streaming, with or witout DOM impl
etc.
> [9/15/2004 8:33 AM] <gdaniels> in SOAP it does too, Sanjiva - IF you care about
it.  SOAP certainly does not say "whitespace is irrelevant"
> [9/15/2004 8:33 AM] <alek_s> so fro security one would configure OM to have full
ODM support ...
> [9/15/2004 8:33 AM] <gdaniels> essentially there are a variety of switches
> [9/15/2004 8:33 AM] <Srinath> that make things complecated
> [9/15/2004 8:34 AM] <alek_s> i think switches are OK
> [9/15/2004 8:34 AM] <gdaniels> We already know about the om.buildYourselfCompletely()
kind of thing
> [9/15/2004 8:34 AM] <alek_s> as there os no way around it ...
> [9/15/2004 8:34 AM] <Ajith4102> this seems way too complicated
> [9/15/2004 8:34 AM] <sanjiva> No we can't "configure OM" just for security .. it
has to be there the whole time
> [9/15/2004 8:34 AM] <gdaniels> it may be that there are others
> [9/15/2004 8:34 AM] <sanjiva> Unless we decide before reading a message whether
security is there or not
> [9/15/2004 8:34 AM] <sanjiva> which we can do I guess
> [9/15/2004 8:34 AM] <Deepal> if we support all eleven inor set item , what we really
going to implemnt ?
> [9/15/2004 8:35 AM] <Srinath> white space needed a Node like interface I belive
> [9/15/2004 8:35 AM] <gdaniels> Sanjiva : keeping around the entire infoset is expensive,
no way around that.  In many/most cases, we won't care.  So we need to design things to know
(by looking at what Handlers want/do) whether or not we need to keep a "high-fidelity" verison
around.
> [9/15/2004 8:35 AM] <alek_s> Sanjiva: i think we should have those switches if
they do make noticable performance impact
> [9/15/2004 8:35 AM] <Srinath> at the top
> [9/15/2004 8:35 AM] <alek_s> so somebody who implements WS and do not need DOM
can do this with streaming OM ....
> [9/15/2004 8:35 AM] <gdaniels> We tried this with the current stuff but because
it was build on top of existing code it didn't work as well as it should
> [9/15/2004 8:35 AM] <gdaniels> alek : +1
> [9/15/2004 8:35 AM] <sanjiva> ok good - so we want an API that *can* rep the whole
infoset but maybe it won't have it necessarily?
> [9/15/2004 8:35 AM] <gdaniels> We now have a chance to do it again right.
> [9/15/2004 8:35 AM] <gdaniels> yes yes
> [9/15/2004 8:36 AM] <alek_s> Sanjiva: exactly
> [9/15/2004 8:36 AM] <Ajith4102> All :  are we discussing whether we should have
a DOM like build mechanism or else.? is it
> [9/15/2004 8:36 AM] <Deepal> I agree with Sanjiva
> [9/15/2004 8:36 AM] <Srinath> do do it we need the DOM like thing .. e.g. JDOM
lose white space I belive
> [9/15/2004 8:37 AM] <dasarathw> but we need whitespace here right?
> [9/15/2004 8:37 AM] <Chinthaka> JDOM do not lose whitespace information !!
> [9/15/2004 8:37 AM] <gdaniels> We need whitespace sometimes
> [9/15/2004 8:37 AM] <Srinath> with nodes .. NodeList getChilds()
> [9/15/2004 8:37 AM] <sanjiva> We need to have Node type thing with children nodes
like TextNode, ElementNode etc. (like DOM) - if we know we don't need to retain whitespace
then we can skip the textnodes with whitespace etc. (esp. ignoreable whitespace)
> [9/15/2004 8:38 AM] <Srinath> in that case we may able to consider implementing
DOM interfaces directly
> [9/15/2004 8:38 AM] <Deepal> yes Srinath
> [9/15/2004 8:39 AM] <Srinath> and thorw unsupported exceptions where we do nt support
> [9/15/2004 8:39 AM] <Ajith4102> Sanjiva :  Do we really need to retain the whitespaces?
I mean even with SOAP messages
> [9/15/2004 8:39 AM] <dasarathw> what about mixed content>
> [9/15/2004 8:39 AM] <sanjiva> Ajith: That's what we were talking about .. if you
want to run ws-security then you *have to* retain whitespace.
> [9/15/2004 8:39 AM] <alek_s> i think we should not loose any XML infoset content
...
> [9/15/2004 8:39 AM] <dasarathw> with soap we don't need that? or do we
> [9/15/2004 8:40 AM] <Ajith4102> Srinath : oops are you suggesting that we keep
ourselves to DOM interfaces????
> [9/15/2004 8:40 AM] <gdaniels> alek : by default, sure.  But we should be able
to determine that for a simple RPC-type service invocation, we don't need the whole thing
and we don't need ignorable whitespace.
> [9/15/2004 8:40 AM] <Ajith4102> hmmmmmmm
> [9/15/2004 8:40 AM] <dasarathw> :(
> [9/15/2004 8:40 AM] <Ajith4102> this means that building an infoset from scratch
may not be needed than
> [9/15/2004 8:41 AM] <Srinath> Ajith4102: if it is DOM like (retain XML infoset
info ) why not do he last part .. implement it
> [9/15/2004 8:41 AM] <Srinath> make warappeing easy
> [9/15/2004 8:41 AM] <gdaniels> I think we need to build a prototype at this point
to see where it makes sense to implement DOM and where it makes sense to do something else.
> [9/15/2004 8:42 AM] <Srinath> that means we need to retains CDATA ect .. at the
OM level as well?
> [9/15/2004 8:42 AM] <gdaniels> Srinath : definitely.  At least we need to support
retaining it.
> [9/15/2004 8:42 AM] <Ajith4102> What I was thinking is an infoset representation
from scratch that may not reatain EVERY infoset info but the ones that are absolutely necessary
for SOAP (axis)
> [9/15/2004 8:42 AM] <Srinath> yes glen +1 shall we try a phototype
> [9/15/2004 8:43 AM] <sanjiva> Srinath: If the switch "retain full infoset" is turned
on, then yes we need to keep everything as is ... including junk like <foo><!-- comment
-->12</foo>
> [9/15/2004 8:43 AM] <Srinath> yap ..
> [9/15/2004 8:43 AM] <alek_s> it looks to me that not retaining whites spaces may
be another feature that can be requested of OM factory ...
> [9/15/2004 8:43 AM] <sanjiva> Actually, how about looking at the XPath/XQuery data
model and considering that as the base of the OM impl? That's a "refined" version of the XML
Infoset and it does things like normalization
> [9/15/2004 8:44 AM] <alek_s> +1 to *multiple* prtotypes
> [9/15/2004 8:44 AM] <alek_s> XPath1 or XPath2?
> [9/15/2004 8:44 AM] <sanjiva> Why do we need factories? IMO we should have one
impl with built in switches rather than multiple implementations (in the final stuff - no
problem with prototypes)
> [9/15/2004 8:44 AM] <Ajith4102> Sanjiva : ok I got the point. So we have to impl
the full functionality with switches to on/off certain features
> [9/15/2004 8:45 AM] <gdaniels> factory == the way you get an OM structure, not
an OM implementation
> [9/15/2004 8:45 AM] <gdaniels> (I think that's what Alek meant)
> [9/15/2004 8:45 AM] <alek_s> factory will allow to add more switches in future
and to swap in different OM implementing classes without need to change user code ...
> [9/15/2004 8:45 AM] <gdaniels> i.e. omFactory.parseDocument(inputStream, options)
> [9/15/2004 8:46 AM] <gdaniels> I guess it's the way you get an implementation too....
> [9/15/2004 8:46 AM] <alek_s> i think factory may be implying too much - i was thinking
more about like different builders
> [9/15/2004 8:46 AM] <alek_s> domBuilder, streamBuilder, ...
> [9/15/2004 8:46 AM] <Srinath> adding or remove a factory later will not be abig
deal any way if we need it
> [9/15/2004 8:47 AM] <Ajith4102> I was thinking of a totally different approach
. to incorporate the build mechanism into the OM element direclty
> [9/15/2004 8:47 AM] <Ajith4102> I mean you dont have dedicated builders as such
> [9/15/2004 8:49 AM] <gdaniels> Ajith : not sure I understand - you've got an InputStream
"is"... how do you get OM for that?  new OMElement(InputStream)?
> [9/15/2004 8:49 AM] <Ajith4102> well something like this
> [9/15/2004 8:50 AM] <Ajith4102> you pass the stream or the pullparser itself at
the construction
> [9/15/2004 8:50 AM] <Srinath> may be we have  factory .. but not big deal to chang
it if we feel like later
> [9/15/2004 8:50 AM] <Chinthaka> one thing who is deciding the options for the OM
build factory ?
> [9/15/2004 8:50 AM] <gdaniels> the OM API doesn't care about that, Chinthaka
> [9/15/2004 8:50 AM] <Ajith4102> and the elements build themselves (as and when
needed)
> [9/15/2004 8:50 AM] <alek_s> i think we need to have list of use cases for OM to
help determine what OM options are required
> [9/15/2004 8:50 AM] <gdaniels> For us, it'll be the engine
> [9/15/2004 8:51 AM] <Srinath> I have put few use cases at the wiki
> [9/15/2004 8:51 AM] <Srinath> OM requirement page
> [9/15/2004 8:51 AM] <alek_s> ultimately service developer and deployer should be
able to fine tune OM for particula ussage pattern ...
> [9/15/2004 8:51 AM] <Ajith4102> mmm shall I try to do a simple impl of my concept
and try to put that in svn at the end of this week perhaps
> [9/15/2004 8:52 AM] <Srinath> +1 ajith
> [9/15/2004 8:52 AM] <Ajith4102> so that you guys are able to look at the approach
and comment abt it
> [9/15/2004 8:52 AM] <alek_s> Srinath: i think we need to make it into a separate
page and expand into more details and impllicaitons for OM
> [9/15/2004 8:52 AM] <Srinath> http://wiki.apache.org/ws/FrontPage/Architecture/OMRequirements
> [9/15/2004 8:52 AM] <Ajith4102> alek : pls tell us what you mean by "implications"
> [9/15/2004 8:53 AM] <Ajith4102> I mean what kind of things do you have in mind
> [9/15/2004 8:53 AM] <Srinath> shall we try to finalize on OM requirements ..
> [9/15/2004 8:53 AM] <alek_s> if you have use case to support streaming that implies
that OM must allow streaming ...
> [9/15/2004 8:54 AM] <Srinath> that is 1) 2)it need pull infoset support
> [9/15/2004 8:54 AM] <alek_s> now that clearly conficts with use case of supporting
WS-security where whole XML document must be retained in memory and represented with DOM to
withr WSS4J and security libs that requires DOM ...
> [9/15/2004 8:55 AM] <alek_s> what is 1) and 2) ?
> [9/15/2004 8:55 AM] <Srinath> I feel we are all having far differant pics of OM
 !!! :(
> [9/15/2004 8:55 AM] <gdaniels> alek : there's no conflict there
> [9/15/2004 8:55 AM] <gdaniels> Srinath : I don't think we are. :)  Perhaps just
different words.
> [9/15/2004 8:55 AM] <Srinath> I like to finalize use cases
> [9/15/2004 8:55 AM] <alek_s> Glen: you mean yo can do streaming and have whole
document in memory?
> [9/15/2004 8:55 AM] <Srinath> :)
> [9/15/2004 8:55 AM] <gdaniels> alek : If you want streaming, you ask for the PullStream
reference.  If you want walkable objects, you use the child/parent APIs
> [9/15/2004 8:56 AM] <Srinath> +1 glen
> [9/15/2004 8:56 AM] <gdaniels> alek: Yes, exactly.  Obviously it's not "real" streaming
where the data gets processed and disappears, but that's the tradeoff
> [9/15/2004 8:56 AM] <Srinath> streming and security can be supporte once
> [9/15/2004 8:56 AM] <alek_s> Glen: when you stream you do not retain elements
> [9/15/2004 8:56 AM] <gdaniels> The model LETS you do real streaming (of the body)
without retention
> [9/15/2004 8:56 AM] <sanjiva> alek: unless u ask the OM to cache ...
> [9/15/2004 8:56 AM] <alek_s> just a matter of defintion ...
> [9/15/2004 8:56 AM] <gdaniels> but only in situations where it's allowed
> [9/15/2004 8:57 AM] <Srinath> yes we make simple case work fast
> [9/15/2004 8:57 AM] <alek_s> that is not streaming but incremental building of
OM ...
> [9/15/2004 8:57 AM] <gdaniels> The security handler is going to say om.buildYourSelfCompletely
> [9/15/2004 8:57 AM] <gdaniels> right right
> [9/15/2004 8:57 AM] <Ajith4102> alek :  that is the diff in our model . we cache
while streaming
> [9/15/2004 8:57 AM] <gdaniels> but the point is that in cases where no one NEEDS
the whole model, the code that asks for the PullStream gets the ACTUAL pullstream, the one
behind the
> [9/15/2004 8:57 AM] <gdaniels> OM
> [9/15/2004 8:58 AM] <gdaniels> and it can then "really" stream without building
the model
> [9/15/2004 8:58 AM] <Srinath> unless somebody accsess the boy it is rally streaming
> [9/15/2004 8:59 AM] <Srinath> when someone do he got pay
> [9/15/2004 8:59 AM] <Srinath> got to pay
> [9/15/2004 8:59 AM] <alek_s> i think we need to be careful with caching
> [9/15/2004 8:59 AM] <gdaniels> in what way, alek?
> [9/15/2004 8:59 AM] <alek_s> i actuually would like to avoid "invisible" caching
as mcuh as possible or we get something like  "recordable" SAX events back ...
> [9/15/2004 9:00 AM] <Ajith4102> mmm I have a very simple impl that I did during
the summit
> [9/15/2004 9:00 AM] <gdaniels> Alek : what's wrong with that?  It's not a bad idea,
it's just that the current Axis implemetation of it is suboptimal
> [9/15/2004 9:00 AM] <Ajith4102> perhaps it may be helpful in seeing what we areaaly
talking about
> [9/15/2004 9:00 AM] <gdaniels> You don't cache SAX events, you cache infoset structure,
but it's essentially the same thing
> [9/15/2004 9:01 AM] <alek_s> if you want you should be able to do "real" streaming
using OM API
> [9/15/2004 9:01 AM] <sanjiva> we're not doing invisible caching - u have to ask
the OM to cache or ask for the non-caching pull
> [9/15/2004 9:01 AM] <Srinath> yes with pull parser am positive we can get it right
> [9/15/2004 9:01 AM] <alek_s> SAX events and infoset structure are almost the same
...
> [9/15/2004 9:01 AM] <alek_s> and pull parser events are almost the same as SAX
events
> [9/15/2004 9:01 AM] <gdaniels> Alek: of course you can do "real" streaming, but
only if it's set up right
> [9/15/2004 9:02 AM] <Srinath> but we should keep some benchmarks and make sure
things in right track
> [9/15/2004 9:02 AM] <gdaniels> Srinath : +1
> [9/15/2004 9:02 AM] <alek_s> all are expressing the same information (XML infoset)
with different approaches
> [9/15/2004 9:02 AM] -->| Essington_ (~Essington@essington.user) has joined #apache-axis
> [9/15/2004 9:02 AM] <Srinath> :) ..
> [9/15/2004 9:02 AM] <alek_s> +1 to measure prorotypes
> [9/15/2004 9:02 AM] <gdaniels> alek : there's no way I can think of to get around
building a full-fidelity model when you need to do security or intermediary stuff that requires
a solid copy of the XML
> [9/15/2004 9:02 AM] <Ajith4102> The best thing I see right now is to make one simple
thing and mesure its perf
> [9/15/2004 9:02 AM] <gdaniels> We just have to do it as well as we can
> [9/15/2004 9:02 AM] <Ajith4102> alek : you are right
> [9/15/2004 9:03 AM] <Srinath> can we make palns for phototypes ?
> [9/15/2004 9:03 AM] =-= Essington_ is now known as Essington
> [9/15/2004 9:03 AM] <sanjiva> srinath: p*r*ototypes :)
> [9/15/2004 9:04 AM] <dasarathw> ;-)
> [9/15/2004 9:04 AM] <Srinath> oops :)
> [9/15/2004 9:04 AM] <Srinath> I did it agien
> [9/15/2004 9:04 AM] <chathura> :-D
> [9/15/2004 9:04 AM] <gdaniels> :) again :)
> [9/15/2004 9:04 AM] <dasarathw> too much photography i suppose
> [9/15/2004 9:05 AM] <Srinath> what photogaphy
> [9/15/2004 9:05 AM] <dasarathw> oh u don't do it
> [9/15/2004 9:05 AM] <alek_s> i think we need prorotypes
> [9/15/2004 9:05 AM] <Ajith4102> ok back to business
> [9/15/2004 9:05 AM] <dasarathw> yes
> [9/15/2004 9:05 AM] <Srinath> yes ..plans
> [9/15/2004 9:06 AM] <dasarathw> plans abt phototypes:)
> [9/15/2004 9:06 AM] <alek_s> i have to leave in few mins
> [9/15/2004 9:07 AM] <Srinath> are we including the encoding built in to the OM?
> [9/15/2004 9:07 AM] <dasarathw> doesn't it come at the parser level?
> [9/15/2004 9:07 AM] <Deepal> do we need taht
> [9/15/2004 9:08 AM] =-= gdaniels is now known as glen-busy
> [9/15/2004 9:08 AM] <Srinath> :)
> [9/15/2004 9:09 AM] <Srinath> I have few more issues ..
> [9/15/2004 9:10 AM] =-= YOU are now known as alek-leaving
> [9/15/2004 9:10 AM] <Srinath> e.g. what is the best way to parse the XML DD's
> [9/15/2004 9:10 AM] <Srinath> 2) are we using the javax.xml.NameSpaces
> [9/15/2004 9:11 AM] <FR^2> Hi, Essington
> [9/15/2004 9:12 AM] <Srinath> everybody is silent :)
> [9/15/2004 9:13 AM] <Srinath> hello
> [9/15/2004 9:13 AM] <Deepal> did we stop ?
> [9/15/2004 9:14 AM] -->| sanjiva_ (~sanjiva@fw54.torolab.ibm.com) has joined #apache-axis
> [9/15/2004 9:15 AM] <chathura> i think i gotta go ppl
> [9/15/2004 9:15 AM] <Deepal> really
> [9/15/2004 9:15 AM] <Deepal> :)
> [9/15/2004 9:15 AM] <dasarathw> Srinath: is the conclusion that we implement prototypes
starting from pull that support DOM?
> [9/15/2004 9:15 AM] <Srinath> mmm .....
> [9/15/2004 9:16 AM] <Ajith4102> Seems YES to me
> [9/15/2004 9:16 AM] <Srinath> let us ask it in the mailing list
> [9/15/2004 9:16 AM] <dasarathw> then we go and see whether we can do ws-sec on
those
> [9/15/2004 9:16 AM] <Srinath> yes we would go to prototypes for sure
> [9/15/2004 9:16 AM] <dasarathw> and how much of DOM we can leave out
> [9/15/2004 9:16 AM] <sanjiva_> not all of DOM - can you guys take a look at the
xpath data model?
> [9/15/2004 9:16 AM] <Deepal> wew will
> [9/15/2004 9:16 AM] <sanjiva_> both xpath1 and xpath2 .. that will give a good
model for a reduced infoset type thing ...
> [9/15/2004 9:16 AM] <chathura> i think preserving the infoset is the main concern
ppl
> [9/15/2004 9:17 AM] <sanjiva_> XML allows weird stuff like this:
> [9/15/2004 9:17 AM] |<-- sanjiva has left irc.freenode.net (Read error: 60 (Operation
timed out))
> [9/15/2004 9:17 AM] <sanjiva_> <foo>1234<!-- this is a comment inside
the number -->5678</foo>
> [9/15/2004 9:17 AM] <Ajith4102> yeah. I thought we do  not need to adhere strictly
to infoset preservation :(
> [9/15/2004 9:17 AM] <sanjiva_> that whole element is a number with value 12345678
...
> [9/15/2004 9:17 AM] <Srinath> sure sir should we try to implements the DOM if possible
> [9/15/2004 9:18 AM] <dasarathw> sir
> [9/15/2004 9:18 AM] <dasarathw> is that a valid soap type
> [9/15/2004 9:18 AM] <sanjiva_> the xpath data model cleans up such junk to produce
<foo> with a a child node containing an int of value 12345678
> [9/15/2004 9:18 AM] <sanjiva_> why is that not valid in soap? I thought soap didn't
reject comments?
> [9/15/2004 9:18 AM] <Srinath> soap do not support comment I belive
> [9/15/2004 9:19 AM] <Srinath> if I remeber correct
> [9/15/2004 9:19 AM] <Deepal> for the first stage do we need do think all of those
?
> [9/15/2004 9:19 AM] <sanjiva_> oh that's excellent .. good
> [9/15/2004 9:19 AM] <dasarathw> no
> [9/15/2004 9:19 AM] <dasarathw> the point is
> [9/15/2004 9:19 AM] <Srinath> :)
> [9/15/2004 9:19 AM] <dasarathw> is it necessary to support something
> [9/15/2004 9:20 AM] <dasarathw> like that...
> [9/15/2004 9:21 AM] <Srinath> to sum up .. we would try OM protoypes
> [9/15/2004 9:22 AM] <dasarathw> yes
> [9/15/2004 9:22 AM] <Ajith4102> and then evaluate them
> [9/15/2004 9:22 AM] <alek-leaving> +1 for implemting prorotypes, checking that
use cases can be supprted and evaluting memory footprint / performance
> [9/15/2004 9:22 AM] <Srinath> 1) we got to find the DOM subset we gpt to support
> [9/15/2004 9:22 AM] <Srinath> 2)look at the Xpath impl fpr possible models
> [9/15/2004 9:23 AM] <alek-leaving> jaxen is one impl of xpath1
> [9/15/2004 9:23 AM] <alek-leaving> it works on top of DOM, JDOM etc
> [9/15/2004 9:24 AM] <Srinath> 3) I will add the DOM subset in the wiki pls edit
it
> 
> 



-- 
Ajith Ranabahu

Mime
View raw message