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.
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
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109