Skip to main content

code review for added interview question

5 replies [Last post]
Anonymous

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Allen Wang

Hi Alexander,

We could make those transport constants public in CommInterview.
However, then client of CDCDTFInterview would have to refer to
CommInterview in order to create/configure DTFInterview. This will
reveal the implementation detail of CDCDTFInterview. I would like to
avoid that if possible.

I also do not like the idea of using interface to define constants
because interface should only be used to define types. See Joshua
Bloch's book "Effective Java", Item 17.

I will rename the class to TransportConstants as you suggested.

Thanks,
Allen

Alexander Alexeev wrote:

> Hi Allen,
>
> I understand that we use these constants in CDCDTFInterview and think
> using
> CommInterview.HTTP_TRANSPORT is more appropriate then
> InterviewConstants.HTTP_TRANSPORT since clear indicate what for this
> constant
> are. But it up to you to decide. If you decide to leave constants in
> separate
> class seems it can be renamed to something like TransportConstants and be
> changed to interface.
>
> Thanks,
> Alexander
>
> Allen Wang wrote:
>
>> Hi Alexander,
>>
>> Transport constants will also be used by CDCDTFInterview clients. We
>> have the API in CDCDTFInterview:
>>
>> /**
>> * Set the transport mode for communication.
>> *
>> * @param mode transport mode defined in InterviewConstants
>> */
>> public void setTransportMode(int mode) {
>> commInterview.setTransport(mode);
>> }
>>
>> Thanks,
>> Allen
>>
>> Alexander Alexeev wrote:
>>
>>> Hi Allen,
>>>
>>> changes look good. What about my propose?:
>>> >> Seems that transport constants could be made public straight in the
>>> >> CommInerview because they are only used for the setting up
>>> >> CommInetrview and make sense only for it.
>>>
>>> Thanks,
>>> Alexander
>>>
>>> Allen Wang wrote:
>>>
>>>> Hi Alexander,
>>>>
>>>> I agree with your comments. The updated review is attached.
>>>>
>>>> Thanks,
>>>> Allen
>>>>
>>>> Alexander Alexeev wrote:
>>>>
>>>>> Hi Allen,
>>>>>
>>>>> please see the comments below.
>>>>>
>>>>> Allen Wang wrote:
>>>>>
>>>>>> Hi Alexander,
>>>>>>
>>>>>>> Does CommInterview make sense for CDC-stack TCKs without DTF (as
>>>>>>> for the CLDC-stack)? If yes then it possible to move creation of
>>>>>>> CommInterview outside DTFInterview in the upper level interview.
>>>>>>> This allow to reuse DTFInterview in the MIDP mode also. If not
>>>>>>> then CommInterview in the DTFInterview should be created in CDC
>>>>>>> mode only.
>>>>>>>
>>>>>>>
>>>>>> I couldn't think of a CDC stack TCK which may need CommInterview
>>>>>> only. Even if there is one, it can just reuse CommInterview
>>>>>> without having to touch DTFInterview, right? We can see
>>>>>> DTFInterview as a wrapper around CommInterview with a few more
>>>>>> optional questions related to DTF for added convenience for TCKs
>>>>>> which have distributed tests.
>>>>>>
>>>>>> Right now, I don't think MIDP TCK will use DTFInterview because
>>>>>> it does not care about passive agent. The only benefit for MIDP
>>>>>> TCK to use DTFInterview is that it could reuse the questions for
>>>>>> JavaTest host IP address and remote verboseness for free, which
>>>>>> is not a big deal. Also, DTFInterview exports variables that may
>>>>>> have different names in MIDP TCK interview, like passiveHost and
>>>>>> passivePort. So I would say DTFInterview is not ready (or worth)
>>>>>> to be shared with MIDP TCK interview.
>>>>>>
>>>>>> In the spirit of "when in doubt, leave it out", I agree that we
>>>>>> should just hard code the CDC mode when creating CommInterview
>>>>>> and remove the argument "mode" from the constructors. We can
>>>>>> always add support for CLDC stack TCK in DTFInterview if it is
>>>>>> required later. What do you think?
>>>>>>
>>>>>
>>>>> agreed about hard code CDC mode in DTFInterview and I propose to
>>>>> rename it to something like CdcDTFInterview.
>>>>>
>>>>>>> And I propose to split constants in two classes with appropriate
>>>>>>> names: one class for transports' constants and another for
>>>>>>> modes' constants.
>>>>>>>
>>>>>>>
>>>>>> I don't see any significant benfit for doing this. Why do we need
>>>>>> to introduce an extra class for only two constants?
>>>>>>
>>>>>
>>>>> Currently absolutely different entities combined into one class
>>>>> with meaningless name. It's really hard for the third person to
>>>>> understand what for these constants are.
>>>>>
>>>>> Seems that transport constants could be made public straight in
>>>>> the CommInerview because they are only used for the setting up
>>>>> CommInetrview and make sense only for it.
>>>>>
>>>>> Thanks,
>>>>> Alexander
>>>>>
>>>>>> Thanks,
>>>>>> Allen
>>>>>>
>>>>>> meframework@mobileandembedded.org wrote:
>>>>>>
>>>>>>> Hi Allen,
>>>>>>>
>>>>>>> OK, lets don't touch VmInterview.
>>>>>>>
>>>>>>> Does CommInterview make sense for CDC-stack TCKs without DTF (as
>>>>>>> for the CLDC-stack)? If yes then it possible to move creation of
>>>>>>> CommInterview outside DTFInterview in the upper level interview.
>>>>>>> This allow to reuse DTFInterview in the MIDP mode also. If not
>>>>>>> then CommInterview in the DTFInterview should be created in CDC
>>>>>>> mode only.
>>>>>>>
>>>>>>> And I propose to split constants in two classes with appropriate
>>>>>>> names: one class for transports' constants and another for
>>>>>>> modes' constants.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Alexander
>>>>>>> [Message sent by forum member 'skavas' (skavas)]
>>>>>>>
>>>>>>> http://forums.java.net/jive/thread.jspa?messageID=204836
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>> To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
>>>>>>> For additional commands, e-mail: meframework-help@cqme.dev.java.net
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>> To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
>>>>>> For additional commands, e-mail: meframework-help@cqme.dev.java.net
>>>>>>
>>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
>> For additional commands, e-mail: meframework-help@cqme.dev.java.net
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
For additional commands, e-mail: meframework-help@cqme.dev.java.net

Vladimir Sizikov

Hi Allen, Alexander,

On Wed, Feb 28, 2007 at 09:48:18AM -0800, Allen Wang wrote:
> We could make those transport constants public in CommInterview.
> However, then client of CDCDTFInterview would have to refer to
> CommInterview in order to create/configure DTFInterview. This will
> reveal the implementation detail of CDCDTFInterview. I would like to
> avoid that if possible.

Completely agreed here.
The less interdependencies in our interviews we have the easier it to
understand them and to maintain (and to test, eventually).

> I also do not like the idea of using interface to define constants
> because interface should only be used to define types. See Joshua
> Bloch's book "Effective Java", Item 17.

Agreed too.

Thanks,
--Vladimir

> Alexander Alexeev wrote:
>
> >Hi Allen,
> >
> >I understand that we use these constants in CDCDTFInterview and think
> >using
> >CommInterview.HTTP_TRANSPORT is more appropriate then
> >InterviewConstants.HTTP_TRANSPORT since clear indicate what for this
> >constant
> >are. But it up to you to decide. If you decide to leave constants in
> >separate
> >class seems it can be renamed to something like TransportConstants and be
> >changed to interface.
> >
> >Thanks,
> >Alexander
> >
> >Allen Wang wrote:
> >
> >>Hi Alexander,
> >>
> >>Transport constants will also be used by CDCDTFInterview clients. We
> >>have the API in CDCDTFInterview:
> >>
> >> /**
> >> * Set the transport mode for communication.
> >> *
> >> * @param mode transport mode defined in InterviewConstants
> >> */
> >> public void setTransportMode(int mode) {
> >> commInterview.setTransport(mode);
> >> }
> >>
> >>Thanks,
> >>Allen
> >>
> >>Alexander Alexeev wrote:
> >>
> >>>Hi Allen,
> >>>
> >>>changes look good. What about my propose?:
> >>>>> Seems that transport constants could be made public straight in the
> >>>>> CommInerview because they are only used for the setting up
> >>>>> CommInetrview and make sense only for it.
> >>>
> >>>Thanks,
> >>>Alexander
> >>>
> >>>Allen Wang wrote:
> >>>
> >>>>Hi Alexander,
> >>>>
> >>>>I agree with your comments. The updated review is attached.
> >>>>
> >>>>Thanks,
> >>>>Allen
> >>>>
> >>>>Alexander Alexeev wrote:
> >>>>
> >>>>>Hi Allen,
> >>>>>
> >>>>>please see the comments below.
> >>>>>
> >>>>>Allen Wang wrote:
> >>>>>
> >>>>>>Hi Alexander,
> >>>>>>
> >>>>>>>Does CommInterview make sense for CDC-stack TCKs without DTF (as
> >>>>>>>for the CLDC-stack)? If yes then it possible to move creation of
> >>>>>>>CommInterview outside DTFInterview in the upper level interview.
> >>>>>>>This allow to reuse DTFInterview in the MIDP mode also. If not
> >>>>>>>then CommInterview in the DTFInterview should be created in CDC
> >>>>>>>mode only.
> >>>>>>>
> >>>>>>>
> >>>>>>I couldn't think of a CDC stack TCK which may need CommInterview
> >>>>>>only. Even if there is one, it can just reuse CommInterview
> >>>>>>without having to touch DTFInterview, right? We can see
> >>>>>>DTFInterview as a wrapper around CommInterview with a few more
> >>>>>>optional questions related to DTF for added convenience for TCKs
> >>>>>>which have distributed tests.
> >>>>>>
> >>>>>>Right now, I don't think MIDP TCK will use DTFInterview because
> >>>>>>it does not care about passive agent. The only benefit for MIDP
> >>>>>>TCK to use DTFInterview is that it could reuse the questions for
> >>>>>>JavaTest host IP address and remote verboseness for free, which
> >>>>>>is not a big deal. Also, DTFInterview exports variables that may
> >>>>>>have different names in MIDP TCK interview, like passiveHost and
> >>>>>>passivePort. So I would say DTFInterview is not ready (or worth)
> >>>>>>to be shared with MIDP TCK interview.
> >>>>>>
> >>>>>>In the spirit of "when in doubt, leave it out", I agree that we
> >>>>>>should just hard code the CDC mode when creating CommInterview
> >>>>>>and remove the argument "mode" from the constructors. We can
> >>>>>>always add support for CLDC stack TCK in DTFInterview if it is
> >>>>>>required later. What do you think?
> >>>>>>
> >>>>>
> >>>>>agreed about hard code CDC mode in DTFInterview and I propose to
> >>>>>rename it to something like CdcDTFInterview.
> >>>>>
> >>>>>>>And I propose to split constants in two classes with appropriate
> >>>>>>>names: one class for transports' constants and another for
> >>>>>>>modes' constants.
> >>>>>>>
> >>>>>>>
> >>>>>>I don't see any significant benfit for doing this. Why do we need
> >>>>>>to introduce an extra class for only two constants?
> >>>>>>
> >>>>>
> >>>>>Currently absolutely different entities combined into one class
> >>>>>with meaningless name. It's really hard for the third person to
> >>>>>understand what for these constants are.
> >>>>>
> >>>>>Seems that transport constants could be made public straight in
> >>>>>the CommInerview because they are only used for the setting up
> >>>>>CommInetrview and make sense only for it.
> >>>>>
> >>>>>Thanks,
> >>>>>Alexander
> >>>>>
> >>>>>>Thanks,
> >>>>>>Allen
> >>>>>>
> >>>>>>meframework@mobileandembedded.org wrote:
> >>>>>>
> >>>>>>>Hi Allen,
> >>>>>>>
> >>>>>>>OK, lets don't touch VmInterview.
> >>>>>>>
> >>>>>>>Does CommInterview make sense for CDC-stack TCKs without DTF (as
> >>>>>>>for the CLDC-stack)? If yes then it possible to move creation of
> >>>>>>>CommInterview outside DTFInterview in the upper level interview.
> >>>>>>>This allow to reuse DTFInterview in the MIDP mode also. If not
> >>>>>>>then CommInterview in the DTFInterview should be created in CDC
> >>>>>>>mode only.
> >>>>>>>
> >>>>>>>And I propose to split constants in two classes with appropriate
> >>>>>>>names: one class for transports' constants and another for
> >>>>>>>modes' constants.
> >>>>>>>
> >>>>>>>Thanks,
> >>>>>>>Alexander
> >>>>>>>[Message sent by forum member 'skavas' (skavas)]
> >>>>>>>
> >>>>>>>http://forums.java.net/jive/thread.jspa?messageID=204836
> >>>>>>>
> >>>>>>>---------------------------------------------------------------------
> >>>>>>>
> >>>>>>>To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
> >>>>>>>For additional commands, e-mail: meframework-help@cqme.dev.java.net
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>---------------------------------------------------------------------
> >>>>>>
> >>>>>>To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
> >>>>>>For additional commands, e-mail: meframework-help@cqme.dev.java.net
> >>>>>>
> >>>>>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
> >>For additional commands, e-mail: meframework-help@cqme.dev.java.net
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
> For additional commands, e-mail: meframework-help@cqme.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
For additional commands, e-mail: meframework-help@cqme.dev.java.net

Allen Wang

Hi Alexander,

I have changed the class name to TransportConstants. Please review.

Thanks,
Allen

Vladimir Sizikov wrote:

>Hi Allen, Alexander,
>
>On Wed, Feb 28, 2007 at 09:48:18AM -0800, Allen Wang wrote:
>
>
>>We could make those transport constants public in CommInterview.
>>However, then client of CDCDTFInterview would have to refer to
>>CommInterview in order to create/configure DTFInterview. This will
>>reveal the implementation detail of CDCDTFInterview. I would like to
>>avoid that if possible.
>>
>>
>
>Completely agreed here.
>The less interdependencies in our interviews we have the easier it to
>understand them and to maintain (and to test, eventually).
>
>
>
>>I also do not like the idea of using interface to define constants
>>because interface should only be used to define types. See Joshua
>>Bloch's book "Effective Java", Item 17.
>>
>>
>
>Agreed too.
>
>Thanks,
> --Vladimir
>
>
>
>>Alexander Alexeev wrote:
>>
>>
>>
>>>Hi Allen,
>>>
>>>I understand that we use these constants in CDCDTFInterview and think
>>>using
>>>CommInterview.HTTP_TRANSPORT is more appropriate then
>>>InterviewConstants.HTTP_TRANSPORT since clear indicate what for this
>>>constant
>>>are. But it up to you to decide. If you decide to leave constants in
>>>separate
>>>class seems it can be renamed to something like TransportConstants and be
>>>changed to interface.
>>>
>>>Thanks,
>>>Alexander
>>>
>>>Allen Wang wrote:
>>>
>>>
>>>
>>>>Hi Alexander,
>>>>
>>>>Transport constants will also be used by CDCDTFInterview clients. We
>>>>have the API in CDCDTFInterview:
>>>>
>>>> /**
>>>> * Set the transport mode for communication.
>>>> *
>>>> * @param mode transport mode defined in InterviewConstants
>>>> */
>>>> public void setTransportMode(int mode) {
>>>> commInterview.setTransport(mode);
>>>> }
>>>>
>>>>Thanks,
>>>>Allen
>>>>
>>>>Alexander Alexeev wrote:
>>>>
>>>>
>>>>
>>>>>Hi Allen,
>>>>>
>>>>>changes look good. What about my propose?:
>>>>>
>>>>>
>>>>>>>Seems that transport constants could be made public straight in the
>>>>>>>CommInerview because they are only used for the setting up
>>>>>>>CommInetrview and make sense only for it.
>>>>>>>
>>>>>>>
>>>>>Thanks,
>>>>>Alexander
>>>>>
>>>>>Allen Wang wrote:
>>>>>
>>>>>
>>>>>
>>>>>>Hi Alexander,
>>>>>>
>>>>>>I agree with your comments. The updated review is attached.
>>>>>>
>>>>>>Thanks,
>>>>>>Allen
>>>>>>
>>>>>>Alexander Alexeev wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Hi Allen,
>>>>>>>
>>>>>>>please see the comments below.
>>>>>>>
>>>>>>>Allen Wang wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>Hi Alexander,
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>Does CommInterview make sense for CDC-stack TCKs without DTF (as
>>>>>>>>>for the CLDC-stack)? If yes then it possible to move creation of
>>>>>>>>>CommInterview outside DTFInterview in the upper level interview.
>>>>>>>>>This allow to reuse DTFInterview in the MIDP mode also. If not
>>>>>>>>>then CommInterview in the DTFInterview should be created in CDC
>>>>>>>>>mode only.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>I couldn't think of a CDC stack TCK which may need CommInterview
>>>>>>>>only. Even if there is one, it can just reuse CommInterview
>>>>>>>>without having to touch DTFInterview, right? We can see
>>>>>>>>DTFInterview as a wrapper around CommInterview with a few more
>>>>>>>>optional questions related to DTF for added convenience for TCKs
>>>>>>>>which have distributed tests.
>>>>>>>>
>>>>>>>>Right now, I don't think MIDP TCK will use DTFInterview because
>>>>>>>>it does not care about passive agent. The only benefit for MIDP
>>>>>>>>TCK to use DTFInterview is that it could reuse the questions for
>>>>>>>>JavaTest host IP address and remote verboseness for free, which
>>>>>>>>is not a big deal. Also, DTFInterview exports variables that may
>>>>>>>>have different names in MIDP TCK interview, like passiveHost and
>>>>>>>>passivePort. So I would say DTFInterview is not ready (or worth)
>>>>>>>>to be shared with MIDP TCK interview.
>>>>>>>>
>>>>>>>>In the spirit of "when in doubt, leave it out", I agree that we
>>>>>>>>should just hard code the CDC mode when creating CommInterview
>>>>>>>>and remove the argument "mode" from the constructors. We can
>>>>>>>>always add support for CLDC stack TCK in DTFInterview if it is
>>>>>>>>required later. What do you think?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>agreed about hard code CDC mode in DTFInterview and I propose to
>>>>>>>rename it to something like CdcDTFInterview.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>And I propose to split constants in two classes with appropriate
>>>>>>>>>names: one class for transports' constants and another for
>>>>>>>>>modes' constants.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>I don't see any significant benfit for doing this. Why do we need
>>>>>>>>to introduce an extra class for only two constants?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>Currently absolutely different entities combined into one class
>>>>>>>with meaningless name. It's really hard for the third person to
>>>>>>>understand what for these constants are.
>>>>>>>
>>>>>>>Seems that transport constants could be made public straight in
>>>>>>>the CommInerview because they are only used for the setting up
>>>>>>>CommInetrview and make sense only for it.
>>>>>>>
>>>>>>>Thanks,
>>>>>>>Alexander
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>Thanks,
>>>>>>>>Allen
>>>>>>>>
>>>>>>>>meframework@mobileandembedded.org wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>Hi Allen,
>>>>>>>>>
>>>>>>>>>OK, lets don't touch VmInterview.
>>>>>>>>>
>>>>>>>>>Does CommInterview make sense for CDC-stack TCKs without DTF (as
>>>>>>>>>for the CLDC-stack)? If yes then it possible to move creation of
>>>>>>>>>CommInterview outside DTFInterview in the upper level interview.
>>>>>>>>>This allow to reuse DTFInterview in the MIDP mode also. If not
>>>>>>>>>then CommInterview in the DTFInterview should be created in CDC
>>>>>>>>>mode only.
>>>>>>>>>
>>>>>>>>>And I propose to split constants in two classes with appropriate
>>>>>>>>>names: one class for transports' constants and another for
>>>>>>>>>modes' constants.
>>>>>>>>>
>>>>>>>>>Thanks,
>>>>>>>>>Alexander
>>>>>>>>>[Message sent by forum member 'skavas' (skavas)]
>>>>>>>>>
>>>>>>>>>http://forums.java.net/jive/thread.jspa?messageID=204836
>>>>>>>>>
>>>>>>>>>---------------------------------------------------------------------
>>>>>>>>>
>>>>>>>>>To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
>>>>>>>>>For additional commands, e-mail: meframework-help@cqme.dev.java.net
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>---------------------------------------------------------------------
>>>>>>>>
>>>>>>>>To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
>>>>>>>>For additional commands, e-mail: meframework-help@cqme.dev.java.net
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
>>>>For additional commands, e-mail: meframework-help@cqme.dev.java.net
>>>>
>>>>
>>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
>>For additional commands, e-mail: meframework-help@cqme.dev.java.net
>>
>>
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
>For additional commands, e-mail: meframework-help@cqme.dev.java.net
>
>
>

[att1.html]
---------------------------------------------------------------------
To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
For additional commands, e-mail: meframework-help@cqme.dev.java.net

Vladimir Sizikov

Hi Allen, Alexander,

It seems that we all agree that the latest changes satisfy CDC stack
TCK needs and can be committed to the repository, right?

But I also think that we should take care of other TCK/TestSuite
developers, and provide Framework-related questions in the Framework
interviews, not in TCK-specific interviews. I'm talking about
DTF-related questions.

You see, we have a strange situation here, the support for distributed
tests is in the Framework, but the question for the port and for
verboseness of the DTF infrastructure is not present in the framework,
and every TCK that needs DTF support, implements their own questions.

Also, as Alexander noted earlier, we also have not only MIDP-stack
TCKS, but optional packages TCKs that must work in CLDC/CDC/MIDP
environments. We should be able to accommodate such TCKs.

Here's what I suggest to do:

1. Commit the latest code from Allen
2. Alexander to continue the work on DTF-related interviews, and to
make sure we handle all typical situations. Alexander, you've
already worked with debugging interview improvements, and spent
some time reviewing Allen's interview changes, and now you are
working with other DTF-related TestSuite/Interview bugs, so it
makes a perfect sense to assign you for this task.

What do you think?

If you're agree, Alexander, would you mind filing the Enhancement in
the issue tracker and assign yourself to it?

Thanks,
--Vladimir

On Mon, Mar 05, 2007 at 05:41:16PM -0800, Allen Wang wrote:
> Hi Alexander,
>
> I have changed the class name to TransportConstants. Please review.
>
> Thanks,
> Allen

---------------------------------------------------------------------
To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
For additional commands, e-mail: meframework-help@cqme.dev.java.net

Alexander Alexeev

Hi Vladimir, Allen,

I agree to continue interview improvement. I will submit Enhancement to the
Issue Tracker.

Allen, please commit code to the repository.

Thanks,
Alexander

Vladimir Sizikov wrote:
> Hi Allen, Alexander,
>
> It seems that we all agree that the latest changes satisfy CDC stack
> TCK needs and can be committed to the repository, right?
>
> But I also think that we should take care of other TCK/TestSuite
> developers, and provide Framework-related questions in the Framework
> interviews, not in TCK-specific interviews. I'm talking about
> DTF-related questions.
>
> You see, we have a strange situation here, the support for distributed
> tests is in the Framework, but the question for the port and for
> verboseness of the DTF infrastructure is not present in the framework,
> and every TCK that needs DTF support, implements their own questions.
>
> Also, as Alexander noted earlier, we also have not only MIDP-stack
> TCKS, but optional packages TCKs that must work in CLDC/CDC/MIDP
> environments. We should be able to accommodate such TCKs.
>
> Here's what I suggest to do:
>
> 1. Commit the latest code from Allen
> 2. Alexander to continue the work on DTF-related interviews, and to
> make sure we handle all typical situations. Alexander, you've
> already worked with debugging interview improvements, and spent
> some time reviewing Allen's interview changes, and now you are
> working with other DTF-related TestSuite/Interview bugs, so it
> makes a perfect sense to assign you for this task.
>
> What do you think?
>
> If you're agree, Alexander, would you mind filing the Enhancement in
> the issue tracker and assign yourself to it?
>
> Thanks,
> --Vladimir
>
> On Mon, Mar 05, 2007 at 05:41:16PM -0800, Allen Wang wrote:
>> Hi Alexander,
>>
>> I have changed the class name to TransportConstants. Please review.
>>
>> Thanks,
>> Allen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
> For additional commands, e-mail: meframework-help@cqme.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
For additional commands, e-mail: meframework-help@cqme.dev.java.net