You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by TomohitoNakayama <to...@basil.ocn.ne.jp> on 2005/10/12 14:28:09 UTC
Proposal about creating shared component (Re: Questions about what is module to be shared (Re: Discussions on Wik ... ))
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
tomonaka@basil.ocn.ne.jp
tomohito@rose.zero.ad.jp
tmnk@apache.org
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
----- Original Message -----
From: "David W. Van Couvering" <Da...@Sun.COM>
To: "Derby Development" <de...@db.apache.org>
Sent: Wednesday, October 12, 2005 2:34 AM
Subject: Re: Questions about what is module to be shared (Re: Discussions on Wik ... )
> If I understand correctly, your concerns Tomohito is that you don't know
> whether the versioning guidelines apply until you know better what it is
> we are trying to share. I added my comments to the Wiki page on this,
> and am including it in this email for ongoing discussion:
>
> ====
>
> Let me try to give a sense of what the actual '''components''' would be,
> not just the kinds of things that could be shared. Again, these are all
> possibilities, not realities, and
>
> * '''Common services''' -- these are basic level services that can
> be used across multiple subsystems. This includes things like
> internationalization, common error messages and SQL states,
> !SanityManager, logging/tracing, version info, and other miscellaneous
> shareable services. It is more than possible that functionality which
> starts in this component could end up evolving to be its own separate
> component, but that does not need to be determined ahead of time.
> * '''DRDA networking''' -- providing shared code that is used to
> implement the DRDA protocol. Having this in a shared location helps to
> ensure that the client and server code are in sync in terms of message
> types, message semantics, datatypes, etc.
> * '''Security''' -- provides pluggable security infrastructure that
> is common across client and server
> * '''Common JDBC functionality''' -- this is highly debatable, but
> it could be there is code between the client and embedded drivers that
> is shareable. Again, just a thought, not a commitment.
>
> In terms of how each of these components manages their sharing, I really
> do think this is something that can be defined later. What we want to
> establish are the ground rules for how a shared component is versioned,
> distributed, and what compatibility rules we need to follow. At this
> point we are making no claims to the underlying architecture and
> structure of specific shared components, and I do not feel this needs to
> be identified at this time. For example, we may decide we want a
> common way to load an implementation of an interface at runtime; that is
> a separate discussion and does not need to be defined prior to getting
> in the basic infrastructure as defined in
> SharedComponentVersioningGuidelines.
>
> TomohitoNakayama wrote:
>> Hello.
>>
>> I post my questions around shared module.
>>
>> What is the modules to be shread ?
>>
>> David shows me the list of modules to be shared in next url.
>> http://wiki.apache.org/db-derby/ListOfSharedComponent
>>
>> However, David justs lists them (At least I recognized as so) and,
>> I think we need to think about this list in order to make it clear what
>> is the module to be shared .
>>
>> At first, I think we should think next :
>> * Definition of each element in the lists.
>>
>> And I think what we need to be careful about is as next :
>> * Is granularity of this list reasonable as shared module ?
>> * Are there any other elements which should be included in this lists ?
>> * Is it possible to share the element as the shared module ?
>>
>> Best regards .
>>
>> /*
>>
>> Tomohito Nakayama
>> tomonaka@basil.ocn.ne.jp
>> tomohito@rose.zero.ad.jp
>> tmnk@apache.org
>>
>> Naka
>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>
>> */
>> ----- Original Message ----- From: "David W. Van Couvering"
>> <Da...@Sun.COM>
>> To: "Derby Development" <de...@db.apache.org>
>> Sent: Saturday, October 08, 2005 5:44 AM
>> Subject: Re: Discussions on Wiki - WAS Re: SQL functions, procedures and
>> PSM - a possible approach
>>
>>
>>> Hi, Tomohito. It would be great if you could summarize your concerns
>>> in email and we can continue our discussion on the list.
>>>
>>> If it would help, I'm also more than open for you and I to have an IRC
>>> conversation, log it, and send the log out to the list. We do seem to
>>> be a bit stuck :)
>>>
>>> David
>>>
>>> TomohitoNakayama wrote:
>>>
>>>> Hello.
>>>>
>>>> I understand. Sorry for disturbing .
>>>> I had come to feel difficulties in discussing at Wiki.
>>>>
>>>> Should I ask David my question in mailing list once more ?
>>>>
>>>> Best regards.
>>>>
>>>> /*
>>>>
>>>> Tomohito Nakayama
>>>> tomonaka@basil.ocn.ne.jp
>>>> tomohito@rose.zero.ad.jp
>>>> tmnk@apache.org
>>>>
>>>> Naka
>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>
>>>> */
>>>> ----- Original Message ----- From: "David W. Van Couvering"
>>>> <Da...@Sun.COM>
>>>> To: "Derby Development" <de...@db.apache.org>
>>>> Sent: Friday, October 07, 2005 12:40 PM
>>>> Subject: Re: Discussions on Wiki - WAS Re: SQL functions, procedures
>>>> and PSM - a possible approach
>>>>
>>>>
>>>>> I'm getting a little concerned, it feels a little quiet over there
>>>>> in the corner with Tomohito and I, and I was about to propose with
>>>>> Tomohito that we move it back to the list.
>>>>>
>>>>> David
>>>>>
>>>>> Daniel John Debrunner wrote:
>>>>>
>>>>>> David W. Van Couvering wrote:
>>>>>>
>>>>>>
>>>>>>> This sounds great, Dan! Is this a good candidate for putting up
>>>>>>> on the
>>>>>>> Wiki site as a proposal?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Is anyone else concerned by the movement of discussion to the wiki for
>>>>>> the common code stuff? The Apache way is for discussions to occur
>>>>>> on the
>>>>>> mailing lists. It seems to me that the wiki is a great way to
>>>>>> summarize
>>>>>> such discussions, but not to hold them. A wiki page related to a
>>>>>> discussion can provide a very useful single overview, something that
>>>>>> does get lost in mailings as the discussion spreads out.
>>>>>>
>>>>>> Dan.
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --------------------------------------------------------------------------------
>>>>
>>>>
>>>>
>>>> No virus found in this incoming message.
>>>> Checked by AVG Anti-Virus.
>>>> Version: 7.0.344 / Virus Database: 267.11.13/123 - Release Date:
>>>> 2005/10/06
>>>>
>>>>
>>>>
>>>
>>
>>
>> --------------------------------------------------------------------------------
>>
>>
>>
>> No virus found in this incoming message.
>> Checked by AVG Anti-Virus.
>> Version: 7.0.344 / Virus Database: 267.11.13/124 - Release Date: 2005/10/07
>>
>>
>>
>
Re: Proposal about creating shared component (Re: Questions about
what is module to be shared (Re: Discussions on Wik ... ))
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
Hi, Tomohito. I understand your concerns about sharing code. I think
we all agree there are many advantages in sharing code (I have seen this
many times), but I can also see that it can lead you into traps if you
are not careful.
I agree with you that any new shared component should be put up for a
vote. I can add this to the shared component guidelines page.
With this in place, are you satisfied with the guidelines we have in
place so far?
Thanks,
David
TomohitoNakayama 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
> tomonaka@basil.ocn.ne.jp
> tomohito@rose.zero.ad.jp
> tmnk@apache.org
>
> Naka
> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>
> */
> ----- Original Message ----- From: "David W. Van Couvering"
> <Da...@Sun.COM>
> To: "Derby Development" <de...@db.apache.org>
> Sent: Wednesday, October 12, 2005 2:34 AM
> Subject: Re: Questions about what is module to be shared (Re:
> Discussions on Wik ... )
>
>
>> If I understand correctly, your concerns Tomohito is that you don't know
>> whether the versioning guidelines apply until you know better what it is
>> we are trying to share. I added my comments to the Wiki page on this,
>> and am including it in this email for ongoing discussion:
>>
>> ====
>>
>> Let me try to give a sense of what the actual '''components''' would be,
>> not just the kinds of things that could be shared. Again, these are all
>> possibilities, not realities, and
>>
>> * '''Common services''' -- these are basic level services that can
>> be used across multiple subsystems. This includes things like
>> internationalization, common error messages and SQL states,
>> !SanityManager, logging/tracing, version info, and other miscellaneous
>> shareable services. It is more than possible that functionality which
>> starts in this component could end up evolving to be its own separate
>> component, but that does not need to be determined ahead of time.
>> * '''DRDA networking''' -- providing shared code that is used to
>> implement the DRDA protocol. Having this in a shared location helps to
>> ensure that the client and server code are in sync in terms of message
>> types, message semantics, datatypes, etc.
>> * '''Security''' -- provides pluggable security infrastructure that
>> is common across client and server
>> * '''Common JDBC functionality''' -- this is highly debatable, but
>> it could be there is code between the client and embedded drivers that
>> is shareable. Again, just a thought, not a commitment.
>>
>> In terms of how each of these components manages their sharing, I really
>> do think this is something that can be defined later. What we want to
>> establish are the ground rules for how a shared component is versioned,
>> distributed, and what compatibility rules we need to follow. At this
>> point we are making no claims to the underlying architecture and
>> structure of specific shared components, and I do not feel this needs to
>> be identified at this time. For example, we may decide we want a
>> common way to load an implementation of an interface at runtime; that is
>> a separate discussion and does not need to be defined prior to getting
>> in the basic infrastructure as defined in
>> SharedComponentVersioningGuidelines.
>>
>> TomohitoNakayama wrote:
>>
>>> Hello.
>>>
>>> I post my questions around shared module.
>>>
>>> What is the modules to be shread ?
>>>
>>> David shows me the list of modules to be shared in next url.
>>> http://wiki.apache.org/db-derby/ListOfSharedComponent
>>>
>>> However, David justs lists them (At least I recognized as so) and,
>>> I think we need to think about this list in order to make it clear what
>>> is the module to be shared .
>>>
>>> At first, I think we should think next :
>>> * Definition of each element in the lists.
>>>
>>> And I think what we need to be careful about is as next :
>>> * Is granularity of this list reasonable as shared module ?
>>> * Are there any other elements which should be included in this lists ?
>>> * Is it possible to share the element as the shared module ?
>>>
>>> Best regards .
>>>
>>> /*
>>>
>>> Tomohito Nakayama
>>> tomonaka@basil.ocn.ne.jp
>>> tomohito@rose.zero.ad.jp
>>> tmnk@apache.org
>>>
>>> Naka
>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>
>>> */
>>> ----- Original Message ----- From: "David W. Van Couvering"
>>> <Da...@Sun.COM>
>>> To: "Derby Development" <de...@db.apache.org>
>>> Sent: Saturday, October 08, 2005 5:44 AM
>>> Subject: Re: Discussions on Wiki - WAS Re: SQL functions, procedures and
>>> PSM - a possible approach
>>>
>>>
>>>> Hi, Tomohito. It would be great if you could summarize your concerns
>>>> in email and we can continue our discussion on the list.
>>>>
>>>> If it would help, I'm also more than open for you and I to have an IRC
>>>> conversation, log it, and send the log out to the list. We do seem to
>>>> be a bit stuck :)
>>>>
>>>> David
>>>>
>>>> TomohitoNakayama wrote:
>>>>
>>>>> Hello.
>>>>>
>>>>> I understand. Sorry for disturbing .
>>>>> I had come to feel difficulties in discussing at Wiki.
>>>>>
>>>>> Should I ask David my question in mailing list once more ?
>>>>>
>>>>> Best regards.
>>>>>
>>>>> /*
>>>>>
>>>>> Tomohito Nakayama
>>>>> tomonaka@basil.ocn.ne.jp
>>>>> tomohito@rose.zero.ad.jp
>>>>> tmnk@apache.org
>>>>>
>>>>> Naka
>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>
>>>>> */
>>>>> ----- Original Message ----- From: "David W. Van Couvering"
>>>>> <Da...@Sun.COM>
>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>> Sent: Friday, October 07, 2005 12:40 PM
>>>>> Subject: Re: Discussions on Wiki - WAS Re: SQL functions, procedures
>>>>> and PSM - a possible approach
>>>>>
>>>>>
>>>>>> I'm getting a little concerned, it feels a little quiet over there
>>>>>> in the corner with Tomohito and I, and I was about to propose with
>>>>>> Tomohito that we move it back to the list.
>>>>>>
>>>>>> David
>>>>>>
>>>>>> Daniel John Debrunner wrote:
>>>>>>
>>>>>>> David W. Van Couvering wrote:
>>>>>>>
>>>>>>>
>>>>>>>> This sounds great, Dan! Is this a good candidate for putting up
>>>>>>>> on the
>>>>>>>> Wiki site as a proposal?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Is anyone else concerned by the movement of discussion to the
>>>>>>> wiki for
>>>>>>> the common code stuff? The Apache way is for discussions to occur
>>>>>>> on the
>>>>>>> mailing lists. It seems to me that the wiki is a great way to
>>>>>>> summarize
>>>>>>> such discussions, but not to hold them. A wiki page related to a
>>>>>>> discussion can provide a very useful single overview, something that
>>>>>>> does get lost in mailings as the discussion spreads out.
>>>>>>>
>>>>>>> Dan.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --------------------------------------------------------------------------------
>>>>>
>>>>>
>>>>>
>>>>> No virus found in this incoming message.
>>>>> Checked by AVG Anti-Virus.
>>>>> Version: 7.0.344 / Virus Database: 267.11.13/123 - Release Date:
>>>>> 2005/10/06
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --------------------------------------------------------------------------------
>>>
>>>
>>>
>>> No virus found in this incoming message.
>>> Checked by AVG Anti-Virus.
>>> Version: 7.0.344 / Virus Database: 267.11.13/124 - Release Date:
>>> 2005/10/07
>>>
>>>
>>>
>>
>
Re: Proposal about creating shared component (Re: Questions about what is module to be shared (Re: Discussions on Wik ... ))
Posted by TomohitoNakayama <to...@basil.ocn.ne.jp>.
Hello Francois.
I think it is better if your comment was summarized at
http://wiki.apache.org/db-derby/Security_encryption/decryption_of_network_traffic,_passwords,_etc%2e
//Maybe the title should be changed .....
It will help someone who vote to consider about your new shared component .
//Even though voting were not be held, it will be a good writing for the component .
Best regards .
/*
Tomohito Nakayama
tomonaka@basil.ocn.ne.jp
tomohito@rose.zero.ad.jp
tmnk@apache.org
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
Re: Proposal about creating shared component (Re: Questions about what is module to be shared (Re: Discussions on Wik ... ))
Posted by Francois Orsini <fr...@gmail.com>.
On 10/12/05, TomohitoNakayama <to...@basil.ocn.ne.jp> 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
> tomonaka@basil.ocn.ne.jp
> tomohito@rose.zero.ad.jp
> tmnk@apache.org
>
> 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
Re: Proposal about creating shared component (Re: Questions about
what is module to be shared (Re: Discussions on Wik ... ))
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
Weird Freudian slip. I meant "up to a vote" not "up to avoid." Sorry...
David W. Van Couvering wrote:
> OK, I am proposing that addition of any new packages to a shared
> component be up to avoid. Addition of new classes or methods to an
> existing shared package should not require a vote.
>
> Does that sound reasonable?
>
> Thanks,
>
> David
>
> TomohitoNakayama wrote:
>
>> Hello.
>> Kathey Marsden wrote :
>>
>>> I think the code submission for any new shared
>>> component should require a vote.
>>
>>
>>
>> I think there remains need to think about definition of "new shared
>> component" in this context .
>> Is it new *.java file to be shared ? Or new package to be shared ?
>>
>> I think we should wait for the shared component guidelines page to be
>> updated by David , then discuss the definition.
>>
>> Best regards .
>>
>> /*
>>
>> Tomohito Nakayama
>> tomonaka@basil.ocn.ne.jp
>> tomohito@rose.zero.ad.jp
>> tmnk@apache.org
>>
>> Naka
>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>
>> */
Re: Proposal about creating shared component (Re: Questions about
what is module to be shared (Re: Discussions on Wik ... ))
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
OK, I am proposing that addition of any new packages to a shared
component be up to avoid. Addition of new classes or methods to an
existing shared package should not require a vote.
Does that sound reasonable?
Thanks,
David
TomohitoNakayama wrote:
> Hello.
> Kathey Marsden wrote :
>
>> I think the code submission for any new shared
>> component should require a vote.
>
>
> I think there remains need to think about definition of "new shared
> component" in this context .
> Is it new *.java file to be shared ? Or new package to be shared ?
>
> I think we should wait for the shared component guidelines page to be
> updated by David , then discuss the definition.
>
> Best regards .
>
> /*
>
> Tomohito Nakayama
> tomonaka@basil.ocn.ne.jp
> tomohito@rose.zero.ad.jp
> tmnk@apache.org
>
> Naka
> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>
> */
Re: Proposal about creating shared component (Re: Questions about
what is module to be shared (Re: Discussions on Wik ... ))
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
OK, I'll clarify this on the Wiki page.
David
TomohitoNakayama wrote:
> Hello.
> Kathey Marsden wrote :
>
>> I think the code submission for any new shared
>> component should require a vote.
>
>
> I think there remains need to think about definition of "new shared
> component" in this context .
> Is it new *.java file to be shared ? Or new package to be shared ?
>
> I think we should wait for the shared component guidelines page to be
> updated by David , then discuss the definition.
>
> Best regards .
>
> /*
>
> Tomohito Nakayama
> tomonaka@basil.ocn.ne.jp
> tomohito@rose.zero.ad.jp
> tmnk@apache.org
>
> Naka
> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>
> */
Re: Proposal about creating shared component (Re: Questions about what is module to be shared (Re: Discussions on Wik ... ))
Posted by TomohitoNakayama <to...@basil.ocn.ne.jp>.
Hello.
Kathey Marsden wrote :
> I think the code submission for any new shared
> component should require a vote.
I think there remains need to think about definition of "new shared component" in this context .
Is it new *.java file to be shared ? Or new package to be shared ?
I think we should wait for the shared component guidelines page to be updated by David ,
then discuss the definition.
Best regards .
/*
Tomohito Nakayama
tomonaka@basil.ocn.ne.jp
tomohito@rose.zero.ad.jp
tmnk@apache.org
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
Re: Proposal about creating shared component (Re: Questions about
what is module to be shared (Re: Discussions on Wik ... ))
Posted by Kathey Marsden <km...@sbcglobal.net>.
David W. Van Couvering wrote:
> Hi, Kathey. I have seen in the code and from various emails the
> concern of "client bloat." I don't have the background so I'm sure
> I'm missing something.
>
> I can understand wanting to keep the code base small for J2ME, but my
> understanding is that doesn't involve client/server. What's the need
> to keep the client small since it won't be found in J2ME environments?
Hopefully it will be found in J2ME environments someday, as soon as
someone does the work to make it so. I think it especially important
for client. Wouldn't it make sense to have a lot of clients on small
devices? Small footprint is also part of our charter
http://db.apache.org/derby/#Derby+Project+Charter so is important. On
this whole topic my three concerns are as they have been from the start.
- We need to allow mixing of client and server versions, both on a
protocol level and in the same classpath.
- We should keep jar file growth commensurate with functionality
improvement.
- We should try to avoid asking every user in the world to change their
classpath.
Kathey
Re: Proposal about creating shared component (Re: Questions about
what is module to be shared (Re: Discussions on Wik ... ))
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
Hi, Kathey. I have seen in the code and from various emails the concern
of "client bloat." I don't have the background so I'm sure I'm missing
something.
I can understand wanting to keep the code base small for J2ME, but my
understanding is that doesn't involve client/server. What's the need to
keep the client small since it won't be found in J2ME environments?
Thanks,
David
Kathey Marsden wrote:
> TomohitoNakayama wrote:
>
>
>>Then, I propose next :
>> It is subject of voting to create new shared component . New
>>shared component require passing the vote .
>
>
>
> +1
>
> I too am concerned with the impact of creating shared components
> especially with regard to potential client bloat and backward
> compatibility risks. I think the code submission for any new shared
> component should require a vote. I also think that it would be good to
> componentize things in place in client or server before making them a
> shared component. For example, for DRDA there is a fair amount of work
> to do to extract the sharable parts of DRDA processing from either
> server or client. First the code work for untangling the component
> could be done in place for either server or client and then once
> complete, moved to shared component status.
>
>
> Kathey
>
Re: Proposal about creating shared component (Re: Questions about
what is module to be shared (Re: Discussions on Wik ... ))
Posted by Kathey Marsden <km...@sbcglobal.net>.
TomohitoNakayama wrote:
> Then, I propose next :
> It is subject of voting to create new shared component . New
> shared component require passing the vote .
+1
I too am concerned with the impact of creating shared components
especially with regard to potential client bloat and backward
compatibility risks. I think the code submission for any new shared
component should require a vote. I also think that it would be good to
componentize things in place in client or server before making them a
shared component. For example, for DRDA there is a fair amount of work
to do to extract the sharable parts of DRDA processing from either
server or client. First the code work for untangling the component
could be done in place for either server or client and then once
complete, moved to shared component status.
Kathey