[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] Egg cooking

Hi Scott,

Great idea. I will do that. I have already bought the hotplate and have successfully switched a relay with the remote pins (I did not yet dare to switch a 1000 watt heatplate ;). Next step is to hook up a heat sensor.

Cheers,

Wim


On Sat, Aug 16, 2014 at 12:05 AM, Scott Lewis <slewis@xxxxxxxxxxxxx> wrote:
Hi Wim,

Congrats on the talk acceptance.

After listening to yet another radio show about the 'the Internet of things' (what is it?, why would anyone want it?, how is it going to be made safe?, etc) I had the following idea: perhaps you could show that having guarantees of failure detection for remote service (with an unreliable network) could be shown to make this cooking example *safer*. I'm thinking of the following scenario: say some device (or UI) tells the 'hotplate' device to turn itself on to begin cooking...via a remote service. Suppose that the network connecting these devices goes down for whatever reason, with the hotplate still on (!).

Using one of the remote service providers that does failure detection (e.g. generic, jms), this will mean the host remote service container will get notified about the failure after some configurable timeout, and can take appropriate action (e.g. turn everything off, ring alarms, etc). Via ECF's impl of OSGi Remote Services/RSA, this can all be accessed at the level of the remote service being registered and unregistered...rather than requiring lots of extra app-level code to handle these such failure cases (which obviously don't occur for the local case).

The idea here is to use the dynamics of OSGi (remote) services to represent network failure, rather than requiring the service or app creator to write a lot of app-level functionality to safely handle such cases.ÂÂ This along with the other aspects of ECF's impl of OSGi (remote) services...e.g. discovery, async/sync remoting, high-level service abstractions (service type interfaces), multi-provider support for distribution and discovery, service type versioning, OSGi service-level security/service permissions, could I think make a very strong case for the use of OSGi remote services as a scalable, flexible, IoT communications infrastructure.

Scott


On 8/15/2014 12:35 PM, sakith indula wrote:
yeh that's amazing. congrats.

regards,
Sakith


On Fri, Aug 15, 2014 at 2:26 PM, Harshana Eranga Martin <harshana05@xxxxxxxxx> wrote:
Cool! :-) Congratz!

Thanks and Regards,
Harshana
--
Harshana Eranga Martin
Senior Software Engineer
Asian Mobile Banking
Web: https://www.commbank.com.au/

ECF Committer: http://www.eclipse.org/ecf/
Blog: http://harshana05.blogspot.com
Profile: https://www.google.com/profiles/harshana05


On 15 August 2014 16:46, Wim Jongman <wim.jongman@xxxxxxxxx> wrote:
Hi,

Our talk is accepted [1].

Cheers,

Wim

_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ecf-dev


_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ecf-dev



--
Sakith Indula,
Depatrment of Computing and Information Systems,
Sabaragamuwa University Of Sri Lanka.


_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ecf-dev


_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ecf-dev