- From: Futomi Hatano <futomi.hatano@newphoria.co.jp>
- Date: Tue, 20 Oct 2015 13:04:48 +0900
- To: 전종홍 <hollobit@etri.re.kr>
- Cc: Satoru Takagi <sa-takagi@kddi.com>, "waldron.rick@gmail.com" <waldron.rick@gmail.com>, "public-device-apis@w3.org" <public-device-apis@w3.org>, Public Web of Things IG <public-wot-ig@w3.org>, "public-browserobo@w3.org" <public-browserobo@w3.org>
Thank you for giving me your thought, Jonathan. I replied inline. On Mon, 19 Oct 2015 20:39:29 +0000 전종홍 <hollobit@etri.re.kr> wrote: > In spite of browser running on the device, browsing performance is still not good. Yes, it's no wonder. > I think it is a philosophical problem. I don't think it's a problem for all use cases. > "Browser" is focused on "rendering for human". Yes. But I am considering the future when "Browser" is used as an application platoform. The term of "Browser" might not be appropriate in this context. As you know, Node is based on "Browser" (Chromium), which is used for server-side applications. Node is not used for "rendering for human". > But, generally, hardware control is focusing on "effective controlling for machine". Yes, for cases you are considering. If "Things" refers to Microcontrollers, naturally "Browser" is out of options. Don't get me wrong. I don't say "Browser" is suitable for all cases. I have no thought to replace or deny your (or WoT IG's) ideas. I think that the targets (or use cases) of each idea are different. > So, base on this point of view, we need to find the answer for the question - "we really need to use heavy browsing technology just for controlling the hardware ? Why ?" Just easiness to use (develop). All cases don't necessarily require perfect performance as you say. For example, in the context of development of smartphone apps, hybrid app development becomes popular despite native apps are obviously more effective than hybrid apps. Is this trend also a philosophical problem? "Browser" has already supported a lot of APIs which allow us to access local hardware components such as Gyro, GPS, proximity sensor. I don't know why it is a philosophical problem that "Browser" supports APIs which allow us to access GPIO, I2C, etc. I know you (and WoT guys) are not interested in standardization of JavaScript APIs for Things you are considering. I just want you to understand that there are a lot of Things which you are not considering. Again, I don't deny the ideas you (or WoT IG) are considering. I'm just saying that JavaScript APIs are also usable in many situations. I'm happy to discuss with WoT guys. Thanks again for your comments, Jonathan. Futomi
Received on Tuesday, 20 October 2015 04:05:19 UTC