You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Aleksander Slominski <as...@cs.indiana.edu> on 2004/09/15 19:28:15 UTC
[Axis2] IRC chat log 2004-09-15
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
Re: [Axis2] IRC chat log 2004-09-15
Posted by Ajith Ranabahu <aj...@gmail.com>.
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
<as...@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