axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aleksander Slominski <>
Subject [Axis2] IRC chat log 2004-09-15
Date Wed, 15 Sep 2004 17:28:15 GMT
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



[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@ 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 (Read error: 110 (Connection timed
[9/15/2004 8:11 AM] <Ajith4102> deepal and dasarath still has problems connecting
[9/15/2004 8:11 AM] |<-- Deepal has left (Read error: 110 (Connection
timed out))
[9/15/2004 8:12 AM] -->| dasarathw (~dasarath@ has joined #apache-axis
[9/15/2004 8:12 AM] |<-- dasarath has left (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@ 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@ has joined #apache-axis
[9/15/2004 8:16 AM] <alek_s> how does proposed plan of action look? at
[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
[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 ( 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
[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
[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
[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
[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
[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
[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.
[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
[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
[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
[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
[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
[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>
[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
[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
[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
[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
[9/15/2004 8:57 AM] <gdaniels> OM
[9/15/2004 8:58 AM] <gdaniels> and it can then "really" stream without building the
[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
[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
[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_ ( 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 (Read error: 60 (Operation timed
[9/15/2004 9:17 AM] <sanjiva_> <foo>1234<!-- this is a comment inside the number
[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 

View raw message