Hi Paul,
Paul Sandoz wrote:
> Hi Venu,
>
> So just to summarize you would prefer to use XMLStreamWriter and
> extentions to it to write out pre-encoded UTF-8 infoset?
>
> I can modify/change the ifaces to specify that.
>
Yes I would prefer that , but I am curious to know if I missed on
getting the benefit for InputStreamMessage if any. Kohsuke mentioned
very briefly about it in
his previous mail.
I am inclined to a solution that is best for performance.
Regards,
Venu
> Paul.
>
> Venu wrote:
>> Kohsuke Kawaguchi wrote:
>>
>>>
>>> I'm trying to pick up the discussion of the edge pipe designs.
>>>
>>> - StreamBasedMessage. Paul suggested that we should parameterize
>>> Packet with the actual message type 'T' (where T could be things
>>> like Message or StreamBasedMessage), but because Packet is highly
>>> visible, I'd like to keep it as is.
>>>
>>> The current StreamBasedMessage.properties works (except that
>>> it's ugly, since its message field will always be empty.)
>>>
>>>
>>> - XMLStreamReaderMessage processStreamReader(Packet packet) makes
>>> sense,
>>> as a Message is an XML infoset anyway, but I'm not sure about the
>>> versions that take InputStreamMessage.
>>
>> XMLStreamReaderMessage processStreamReader(InputStreamMessage msg);
>>
>> if you are talking about the above method then yes I would still
>> prefer what is suggested at the end of this mail.
>>
>>
>>>
>>> The first concern is that this breaks the encoder pluggability. At
>>> least we need some negotiation phase so that the security pipe (SP)
>>> can check if the encoding in use is really what it supports.
>>
>>
>>>
>>> Also, I'm convinced enough that going down to the infoset level would
>>> give a performance improvement to SP, but I'm not so convinced about
>>> going down to the stream level. I mean, it seems like SP needs to be
>>> fairly sophisticated to use this correctly. You'd have to produce the
>>> UTF-8 encoded canonical text for the signed portion, keep it on the
>>> side, compute the digest as a filter, then produce headers, then the
>>> buffered body. Is the security team really committed to do this?
>>
>> Yes XWSS 2.0 EA2 already does this to a certain extent.But are you
>> saying you are not convinced that this
>> would improve the performance of the WS stack.
>>
>>>
>>> If they aren't planning to do so right away, we can always defer this
>>> until it's necessary.
>>>
>>> Lastly, using InputStreamMessage seems to imply that SP is going to
>>> cache the whole message in memory
>>
>>
>>
>>> (unless SP is very smart and
>>> implement the whole logic inside out in a InputStream class.) Is that
>>> what's planned, or am I missing something?
>>
>> Can you be more specific on what you are suggesting.Just to ensure I
>> understand you right.
>>
>>>
>>> Instead, wouldn't it be better for the ClientEdgePipe to give SP
>>> a XMLStreamWriter to write to (thus conceptually set the layer to
>>> the infoset layer, not below)?
>>>
>>> XMLStreamWriter would then expose a hint that it's writing to UTF-8
>>> OutputStream in a plain XML (or perhaps also MTOM), and then SP
>>> can switch to write to OutputStream directly. We can use this for
>>> JAXB, too.
>>>
>> Yes this will work just fine and this is what we had requested. If I
>> am not wrong SP layer
>> will need the information to determine if it can use outputstream or
>> XMLStreamWriter.
>>
>>> I think this is cleaner in the sense that I'm only breaking the
>>> abstraction one at a time (instead of going straight from Message
>>> to stream), and each short-cut is usable for other things.
>>>
>>>
>>> - I think similar thing applies to ServerEdgePipe, but let's settle on
>>> ClientEdgePipe first, and we can just apply the same design to SEP.
>>>
>> Apart from this
>>
>> Regards,
>> Venu
>