Visie achter HSTouch (filosofisch :-)
Posted: Sun Jan 18, 2009 12:23 pm
Ik zit nu een tijdje met HSTouch te experimenteren en er vallen me dan toch wel een paar dingen op. Natuurlijk in de eerste plaats de bugs, maar daar valt wel doorheen te kijken. Wat ik meer bedoel is de gedachte/visie die achter het pakket schuil gaat.
HomeSeer werkt in essentie via het client/server model. HomeSeer is de HA server en je webbrowser is de bijzonder dunne (thin) client waarmee je de server benadert.
We kennen allemaal de beperkingen van browsers en nemen die voor lief (denk aan de niet directe statusupdates als je via een schakelaar een device schakelt => eerst een page refresh nodig). Daarnaast kennen we allemaal de tekortkomingen van de niet erg intuitieve HS webinterface (over WAF gesproken).
Nu we echter HSTouch hebben, zie je dat de client een directere verbinding heeft met de server (bijvoorbeeld: directe status update) en dat die client dus ook "dikker" zou kunnen worden (fat client).
Met andere woorden: HSTouch zou veel meer kunnen doen dan alleen maar basale schermafhandeling met een 1-op-1 relatie naar de HomeSeer devices. Ook application logic zou prima aan de HSTouch zijde kunnen zitten.
Sterker nog: conform het traditionele client/server model zou je juist verwachten dat de application logic veelal aan de HSTouch zijde zou zitten. En dat HomeSeer zelf niet veel meer doet dan devices schakelen, values updaten/uitlezen en events draaien die het algemeen belang dienen (los van een specifieke client).
Dat betekent echter: noodzaak voor volledige scripting mogelijkheden aan de HSTouch zijde. Denk dan bijvoorbeeld aan conditionals (if-then-else statements), loops (for-do, while-do), enz.
Om maar wat te noemen: ik zou graag het tonen van schermen/buttons van bepaalde condities af willen laten hangen (staan bepaalde devices aan? Zo ja, toon het controle scherm/de buttons, anders niet). En ik zou soms een wait aan de HSTouch zijde willen inbouwen (zonder daarvoor een script in HS te moeten aanroepen!). Of lokale variabelen willen gebruiken (zonder een virtual device binnen HS te moeten zetten!). En zo zijn er nog wel meer zaken die generieke scripting aan de client zijde wenselijk maken.
Uiteraard kun je hierin ook te ver gaan (op een gegeven moment kun je misschien beter zelf een client gaan schrijven in C# o.i.d.), maar ik heb het gevoel dat de balans nu wel erg naar de "eenvoud"-zijde in plaats van naar de "functionaliteit"-zijde doorslaat. Conditionals die je bij elkaar kunt klikken op basis van device-status/value (zoals je die min of meer ook in het HS event mechanisme hebt) zijn toch eigenlijk wel het minste dat je zou verwachten.
Mijn vraag: sta ik alleen in het gevoel dat er dus eigenlijk nog wel wat ontbreekt aan de HSTouch functionaliteit? Kijk ik op een verkeerde manier tegen de bedoeling van HSTouch aan? Wat zijn jullie gedachten hierover?
My 2 cents,
Lennart
HomeSeer werkt in essentie via het client/server model. HomeSeer is de HA server en je webbrowser is de bijzonder dunne (thin) client waarmee je de server benadert.
We kennen allemaal de beperkingen van browsers en nemen die voor lief (denk aan de niet directe statusupdates als je via een schakelaar een device schakelt => eerst een page refresh nodig). Daarnaast kennen we allemaal de tekortkomingen van de niet erg intuitieve HS webinterface (over WAF gesproken).
Nu we echter HSTouch hebben, zie je dat de client een directere verbinding heeft met de server (bijvoorbeeld: directe status update) en dat die client dus ook "dikker" zou kunnen worden (fat client).
Met andere woorden: HSTouch zou veel meer kunnen doen dan alleen maar basale schermafhandeling met een 1-op-1 relatie naar de HomeSeer devices. Ook application logic zou prima aan de HSTouch zijde kunnen zitten.
Sterker nog: conform het traditionele client/server model zou je juist verwachten dat de application logic veelal aan de HSTouch zijde zou zitten. En dat HomeSeer zelf niet veel meer doet dan devices schakelen, values updaten/uitlezen en events draaien die het algemeen belang dienen (los van een specifieke client).
Dat betekent echter: noodzaak voor volledige scripting mogelijkheden aan de HSTouch zijde. Denk dan bijvoorbeeld aan conditionals (if-then-else statements), loops (for-do, while-do), enz.
Om maar wat te noemen: ik zou graag het tonen van schermen/buttons van bepaalde condities af willen laten hangen (staan bepaalde devices aan? Zo ja, toon het controle scherm/de buttons, anders niet). En ik zou soms een wait aan de HSTouch zijde willen inbouwen (zonder daarvoor een script in HS te moeten aanroepen!). Of lokale variabelen willen gebruiken (zonder een virtual device binnen HS te moeten zetten!). En zo zijn er nog wel meer zaken die generieke scripting aan de client zijde wenselijk maken.
Uiteraard kun je hierin ook te ver gaan (op een gegeven moment kun je misschien beter zelf een client gaan schrijven in C# o.i.d.), maar ik heb het gevoel dat de balans nu wel erg naar de "eenvoud"-zijde in plaats van naar de "functionaliteit"-zijde doorslaat. Conditionals die je bij elkaar kunt klikken op basis van device-status/value (zoals je die min of meer ook in het HS event mechanisme hebt) zijn toch eigenlijk wel het minste dat je zou verwachten.
Mijn vraag: sta ik alleen in het gevoel dat er dus eigenlijk nog wel wat ontbreekt aan de HSTouch functionaliteit? Kijk ik op een verkeerde manier tegen de bedoeling van HSTouch aan? Wat zijn jullie gedachten hierover?
My 2 cents,
Lennart