On Dec 16, 2008, at 8:18 AM, Jeanfrancois Arcand wrote:
> Salut,
>
> looks good...see comment inline. We should look at Hubert reference
> as well (and make sure the licence allow us to use it).
It's licensed in parts according to the presentation: GPL + classpath
exception, and apache 2.0.
I think both of those are OK (with an inbound OSR of course).
Ken.
>
>>
>
> Looks good, but need a more complex example to make sure it works :-)
>
We can certainly include more issues in the GIOP example:
There are 3 (or 4) versions of GIOP, so things like Preon's @If could
be useful.
You can't limit the size of the GIOP body to 8192 bytes (as in
Oleksiy's example): we do limit the size on writes, but any size could
be received (up to 2^31 bytes)
For GIOP 1.2, it makes sense to regard the header as being 16 bytes in
MOST cases (not all), because you really need the request ID to know
how to process a message. We don't do anything quite that complex
today, but it could be useful to know exactly what to do with a
message as soon as possible.
Can we/should we go further? GIOP is actually an extremely complex
binary format. How much sense would it make to try to use something
like preon to handle all protocol parsing?
Preon seems to address only decoding (I think); what about encoding?
One significant problem with defining a protocol is keeping the read
and write code in sync, especially for more complex cases.
I think the preon work looks very interesting. I'm not sure which
approach makes more sense: to continue enhancing
Oleksiy's smart codec, or to dive further into preon (probably a bit
of both). I'm also not sure about the
efficiency of preon, or how well it would fit in an event-driven
transport.
Thanks,
Ken.