On 10/12/05, TomohitoNakayama <[EMAIL PROTECTED]> wrote:
Hello.
I have suspect on next two items.
* '''DRDA networking''' -- providing shared code <snip> message semantics, datatypes, etc.
Because of synmetry between server and client, some part of networking protocol component would be similar implementation
between server and client .
However, I think it can be somekind of trap because there would exists difference of processing between server and client .
* '''Security''' -- provides pluggable security infrastructure that is common across client and server
I'm not sure required security is same between server and client.
Well, all they are just suspect , and not anymore than suspect now .
I can't assert that they are evil, unless they are explained more concretely.
// To say the trugh, I feel some kind of beauty in sharing code in DRDA because of synmetry between server and client , even !
Writing this mail, I noticed that what my concern is the impact and danger of shared component .
I think shared code can become trap very easily,
because shared component can share , not only something which should be shared , but also something which should not be shared ,
between programs.
I feel danger about such a bunch of code being created with silence.
Then, I propose next :
It is subject of voting to create new shared component . New shared component require passing the vote .
Best regards.
/*
Tomohito Nakayama
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
Tomohito,
Pluggable Security Infrastructure is *not* what shared component is bringing to the table - This is definitely a term which can lead to confusion to the notion of shared security component - Pluggable Security Infrastructure is an (infrastructure) implementation and is not directly linked to the way security logic is shared across the client and the server. This should not be mentioned as part of Shared component discussion - not saying you did ;)
Again, there is logic which involves the use of security algorithms which is shared across the client and the server - For instance, encrypting/decrypting ciphered bytes can and will make use of similar if not identical code/logic from *both* the client and a remote Derby engine - to give you an example, some of this logic right now has code *duplicated* in different packages - this is not what we want and we want to share such logic which is being used by the client and the server - Again, this is one particular example - Other ones for instance we particular and computed hashed bytes logic which would have the implementation logic being shared by the client and the Derby engine - this needs to be shared as well...
In respect with JDBC, I could also see logic being shared by the client and Derby engine (logical) tiers at the higher levels, especially in the area of ResultSetMetadata as well as DatabaseMetaData.
--francois
