Should remove virtual from WuClassDef class and also in WuKongStandardLibrary.xml component entries

[pencilcheck]

Even though our code is not using it, we should remove it from the codebase. And also as we have discussed before, we have concluded to get the virtuality (almost the same as implementation since you can't preload java wuclasses on VM), from the devices themselves.

But since this will not hurt the functionality of the runtime, we will fix this in the next release.

[nielsreijers]

How will the codegen know for which classes it needs to generate baseclasses? (or does it just generate them for all defined wuclasses?)

On Sun, Sep 15, 2013 at 1:08 PM, Penn Su notifications@github.com wrote:

Even though our code is not using it, we should remove it from the codebase. And also as we have discussed before, we have concluded to get the virtuality (almost the same as implementation since you can't preload java wuclasses on VM), from the devices themselves.

But since this will not hurt the functionality of the runtime, we will fix this in the next release.

— Reply to this email directly or view it on GitHubhttps://github.com/wukong-m2m/wukong-darjeeling/issues/47 .

_

[pencilcheck]

Yes, we should have a file somewhere that stores the implementations found for each component, then codegen should generate the base class for the particular implementation language.

We shouldn't be limiting ourselves to Java and C right? Maybe in the future we would have Python, Ruby..

Sincerely, Penn

On Mon, Sep 16, 2013 at 1:44 PM, Niels Reijers notifications@github.comwrote:

How will the codegen know for which classes it needs to generate baseclasses? (or does it just generate them for all defined wuclasses?)

On Sun, Sep 15, 2013 at 1:08 PM, Penn Su notifications@github.com wrote:

Even though our code is not using it, we should remove it from the codebase. And also as we have discussed before, we have concluded to get the virtuality (almost the same as implementation since you can't preload java wuclasses on VM), from the devices themselves.

But since this will not hurt the functionality of the runtime, we will fix this in the next release.

— Reply to this email directly or view it on GitHub< https://github.com/wukong-m2m/wukong-darjeeling/issues/47> .

_

— Reply to this email directly or view it on GitHubhttps://github.com/wukong-m2m/wukong-darjeeling/issues/47#issuecomment-24489921 .

[pencilcheck]

We all already agreed that the virtuality of wuclasses depends on the sources. Native wuclasses are compiled and uploaded with the VM at the time of manufacturing by the developers or installers; virtual wuclasses are "added" by WuKong Master.

If virtual still indicates the component target (whether it is hardware resource of computation resource), or whether it can be published, then we shouldn't be merging the hardsoftrefactoring in the first place.

So the virtual attribute in component definition is misleading, since it gives users the impression that some of the components will definitely not have a native implementations so we should be getting rid of it.

Sincerely, Penn

On Mon, Sep 16, 2013 at 3:40 PM, Pencilcheck pennsuaccount@gmail.comwrote:

Yes, we should have a file somewhere that stores the implementations found for each component, then codegen should generate the base class for the particular implementation language.

We shouldn't be limiting ourselves to Java and C right? Maybe in the future we would have Python, Ruby..

Sincerely, Penn

On Mon, Sep 16, 2013 at 1:44 PM, Niels Reijers notifications@github.comwrote:

How will the codegen know for which classes it needs to generate baseclasses? (or does it just generate them for all defined wuclasses?)

On Sun, Sep 15, 2013 at 1:08 PM, Penn Su notifications@github.com wrote:

Even though our code is not using it, we should remove it from the codebase. And also as we have discussed before, we have concluded to get the virtuality (almost the same as implementation since you can't preload java wuclasses on VM), from the devices themselves.

But since this will not hurt the functionality of the runtime, we will fix this in the next release.

— Reply to this email directly or view it on GitHub< https://github.com/wukong-m2m/wukong-darjeeling/issues/47> .

_

— Reply to this email directly or view it on GitHubhttps://github.com/wukong-m2m/wukong-darjeeling/issues/47#issuecomment-24489921 .

[wycc]

The codegen will depend on the virtual flag of each wuobject. Therefore, Penn modify the VM to publish a flag to indicate if a wuobject is virtual or not. If it is virtual, the code need to include the Java implementation of a wuclass.

Therefore, the virtual flag in the XML is used to decide if we have a Java implementation or not. The codegen will use the virtual in the wuobject instead to decide if we need to register the wuobject in the WKDeploy.Java or not.

2013/9/16 Penn Su notifications@github.com

We all already agreed that the virtuality of wuclasses depends on the sources. Native wuclasses are compiled and uploaded with the VM at the time of manufacturing by the developers or installers; virtual wuclasses are "added" by WuKong Master.

If virtual still indicates the component target (whether it is hardware resource of computation resource), or whether it can be published, then we shouldn't be merging the hardsoftrefactoring in the first place.

So the virtual attribute in component definition is misleading, since it gives users the impression that some of the components will definitely not have a native implementations so we should be getting rid of it.

Sincerely, Penn

On Mon, Sep 16, 2013 at 3:40 PM, Pencilcheck pennsuaccount@gmail.comwrote:

Yes, we should have a file somewhere that stores the implementations found for each component, then codegen should generate the base class for the particular implementation language.

We shouldn't be limiting ourselves to Java and C right? Maybe in the future we would have Python, Ruby..

Sincerely, Penn

On Mon, Sep 16, 2013 at 1:44 PM, Niels Reijers notifications@github.comwrote:

How will the codegen know for which classes it needs to generate baseclasses? (or does it just generate them for all defined wuclasses?)

On Sun, Sep 15, 2013 at 1:08 PM, Penn Su notifications@github.com wrote:

Even though our code is not using it, we should remove it from the codebase. And also as we have discussed before, we have concluded to get the virtuality (almost the same as implementation since you can't preload java wuclasses on VM), from the devices themselves.

But since this will not hurt the functionality of the runtime, we will fix this in the next release.

— Reply to this email directly or view it on GitHub< https://github.com/wukong-m2m/wukong-darjeeling/issues/47> .

_

— Reply to this email directly or view it on GitHub< https://github.com/wukong-m2m/wukong-darjeeling/issues/47#issuecomment-24489921>

.

— Reply to this email directly or view it on GitHubhttps://github.com/wukong-m2m/wukong-darjeeling/issues/47#issuecomment-24493480 .

YC

Phone: 886-2-23516989 Mobile: 0919816155

[pencilcheck]

Yes, that's because codegen is designed with the old design in mind, where virtual wuclasses are always implemented in Java. That is useful for now, as we only support C and Java, and only Java code can reprogram nodes wirelessly, so the line between virtual and native wuclasses are easily defined by the language it is implemented in.

However we have discussed about this before, xml definition shouldn't be limiting the type of implementation a component should have, because we shouldn't be assuming that a component can only be implemented in a particular language.

What are the benefit by giving a component a virtual flag? Does that mean that components will not and cannot be compiled or uploaded with VM by the installers or manufacturers? We can always write a convertor and related API in the supported languages that we choose that would let people to write wuclasses in python and convert them into a target language like Java or C or in whatever language we please. That way it is much easier for people to get on wuclass development. Of course they could still be written directly in C or Java. We shouldn't tie components to a particular set of languages.

For example, there are still issues when application could not compiled because codeine couldn't find the implementation in the target language as specified by the virtual flag. I posted those related issues in the tracker a while back #27 https://github.com/wukong-m2m/wukong-darjeeling/issues/27 , #42 https://github.com/wukong-m2m/wukong-darjeeling/issues/42.

On the side note, I don't know if it is possible, but it would be nice if we can allow people to reprogram C virtual wuclasses wirelessly. If we can do that, then there is truly no need to label the component by their implementation language in the definition.

Sincerely, Penn

On Mon, Sep 16, 2013 at 4:51 PM, Yu-Chung Wang notifications@github.comwrote:

The codegen will depend on the virtual flag of each wuobject. Therefore, Penn modify the VM to publish a flag to indicate if a wuobject is virtual or not. If it is virtual, the code need to include the Java implementation of a wuclass.

Therefore, the virtual flag in the XML is used to decide if we have a Java implementation or not. The codegen will use the virtual in the wuobject instead to decide if we need to register the wuobject in the WKDeploy.Java or not.

2013/9/16 Penn Su notifications@github.com

We all already agreed that the virtuality of wuclasses depends on the sources. Native wuclasses are compiled and uploaded with the VM at the time of manufacturing by the developers or installers; virtual wuclasses are "added" by WuKong Master.

If virtual still indicates the component target (whether it is hardware resource of computation resource), or whether it can be published, then we shouldn't be merging the hardsoftrefactoring in the first place.

So the virtual attribute in component definition is misleading, since it gives users the impression that some of the components will definitely not have a native implementations so we should be getting rid of it.

Sincerely, Penn

On Mon, Sep 16, 2013 at 3:40 PM, Pencilcheck pennsuaccount@gmail.comwrote:

Yes, we should have a file somewhere that stores the implementations found for each component, then codegen should generate the base class for the particular implementation language.

We shouldn't be limiting ourselves to Java and C right? Maybe in the future we would have Python, Ruby..

Sincerely, Penn

On Mon, Sep 16, 2013 at 1:44 PM, Niels Reijers < notifications@github.com>wrote:

How will the codegen know for which classes it needs to generate baseclasses? (or does it just generate them for all defined wuclasses?)

On Sun, Sep 15, 2013 at 1:08 PM, Penn Su notifications@github.com wrote:

Even though our code is not using it, we should remove it from the codebase. And also as we have discussed before, we have concluded to get the virtuality (almost the same as implementation since you can't preload java wuclasses on VM), from the devices themselves.

But since this will not hurt the functionality of the runtime, we will fix this in the next release.

— Reply to this email directly or view it on GitHub< https://github.com/wukong-m2m/wukong-darjeeling/issues/47> .

_

— Reply to this email directly or view it on GitHub<

https://github.com/wukong-m2m/wukong-darjeeling/issues/47#issuecomment-24489921>

.

— Reply to this email directly or view it on GitHub< https://github.com/wukong-m2m/wukong-darjeeling/issues/47#issuecomment-24493480>

.

YC

Phone: 886-2-23516989 Mobile: 0919816155

— Reply to this email directly or view it on GitHubhttps://github.com/wukong-m2m/wukong-darjeeling/issues/47#issuecomment-24496225 .

[wycc]

Let's focus on the current situation here. The support for other language and remove the virtual from the XML need separate mechanism. If we decide to support them, we need a separate design document for them since those are not simple feature.

2013/9/16 Penn Su notifications@github.com

Yes, that's because codegen is designed with the old design in mind, where virtual wuclasses are always implemented in Java. That is useful for now, as we only support C and Java, and only Java code can reprogram nodes wirelessly, so the line between virtual and native wuclasses are easily defined by the language it is implemented in.

However we have discussed about this before, xml definition shouldn't be limiting the type of implementation a component should have, because we shouldn't be assuming that a component can only be implemented in a particular language.

What are the benefit by giving a component a virtual flag? Does that mean that components will not and cannot be compiled or uploaded with VM by the installers or manufacturers? We can always write a convertor and related API in the supported languages that we choose that would let people to write wuclasses in python and convert them into a target language like Java or C or in whatever language we please. That way it is much easier for people to get on wuclass development. Of course they could still be written directly in C or Java. We shouldn't tie components to a particular set of languages.

For example, there are still issues when application could not compiled because codeine couldn't find the implementation in the target language as specified by the virtual flag. I posted those related issues in the tracker a while back #27 < https://github.com/wukong-m2m/wukong-darjeeling/issues/27> , #42 https://github.com/wukong-m2m/wukong-darjeeling/issues/42.

On the side note, I don't know if it is possible, but it would be nice if we can allow people to reprogram C virtual wuclasses wirelessly. If we can do that, then there is truly no need to label the component by their implementation language in the definition.

Sincerely, Penn

On Mon, Sep 16, 2013 at 4:51 PM, Yu-Chung Wang notifications@github.comwrote:

The codegen will depend on the virtual flag of each wuobject. Therefore, Penn modify the VM to publish a flag to indicate if a wuobject is virtual or not. If it is virtual, the code need to include the Java implementation of a wuclass.

Therefore, the virtual flag in the XML is used to decide if we have a Java implementation or not. The codegen will use the virtual in the wuobject instead to decide if we need to register the wuobject in the WKDeploy.Java or not.

2013/9/16 Penn Su notifications@github.com

We all already agreed that the virtuality of wuclasses depends on the sources. Native wuclasses are compiled and uploaded with the VM at the time of manufacturing by the developers or installers; virtual wuclasses are "added" by WuKong Master.

If virtual still indicates the component target (whether it is hardware resource of computation resource), or whether it can be published, then we shouldn't be merging the hardsoftrefactoring in the first place.

So the virtual attribute in component definition is misleading, since it gives users the impression that some of the components will definitely not have a native implementations so we should be getting rid of it.

Sincerely, Penn

On Mon, Sep 16, 2013 at 3:40 PM, Pencilcheck pennsuaccount@gmail.comwrote:

Yes, we should have a file somewhere that stores the implementations found for each component, then codegen should generate the base class for the particular implementation language.

We shouldn't be limiting ourselves to Java and C right? Maybe in the future we would have Python, Ruby..

Sincerely, Penn

On Mon, Sep 16, 2013 at 1:44 PM, Niels Reijers < notifications@github.com>wrote:

How will the codegen know for which classes it needs to generate baseclasses? (or does it just generate them for all defined wuclasses?)

On Sun, Sep 15, 2013 at 1:08 PM, Penn Su notifications@github.com

wrote:

Even though our code is not using it, we should remove it from the codebase. And also as we have discussed before, we have concluded to get the virtuality (almost the same as implementation since you can't preload java wuclasses on VM), from the devices themselves.

But since this will not hurt the functionality of the runtime, we will fix this in the next release.

— Reply to this email directly or view it on GitHub< https://github.com/wukong-m2m/wukong-darjeeling/issues/47> .

_

— Reply to this email directly or view it on GitHub<

https://github.com/wukong-m2m/wukong-darjeeling/issues/47#issuecomment-24489921>

.

— Reply to this email directly or view it on GitHub<

https://github.com/wukong-m2m/wukong-darjeeling/issues/47#issuecomment-24493480>

.

YC

Phone: 886-2-23516989 Mobile: 0919816155

— Reply to this email directly or view it on GitHub< https://github.com/wukong-m2m/wukong-darjeeling/issues/47#issuecomment-24496225>

.

— Reply to this email directly or view it on GitHubhttps://github.com/wukong-m2m/wukong-darjeeling/issues/47#issuecomment-24497717 .

[pencilcheck]

Sure. I will open an feature request for adding support for more languages in the future. Removing virtual from XML could be easily solved by modifying codegen to generate base information (or classes) for both C and java and store that in the knowledge base and then Master should know which implementation a particular wuclass has and will use the right one appropriately when deploying.

[pencilcheck]

This is not a pressing issue for this release, but I will leave it here for the record.