search

TelluIoT / ThingML

The ThingML modelling language
https://github.com/TelluIoT/ThingML
Apache License 2.0
102 stars 32 forks source link

Direction on ports #3

Closed ffleurey closed 12 years ago

ffleurey commented 13 years ago

We should have two type of ports to distinguish between required and provided. Maybe we should have "optional" on required ports.

brice-morin commented 13 years ago

How do you then position sent and received w.r.t. to provided and required ports? Can we mix these notions? It seems that a received message should belong to a provided port, and that sent messages should belong to required ports. A bit like in Kevoree (see www.kevoree.org). But so far in ThingML, we can have a port with both sent and received messages...

2011/7/10 ffleurey reply@reply.github.com:

We should have two type of ports to distinguish between required and provided. Maybe we should have "optional" on required ports.

Reply to this email directly or view it on GitHub: https://github.com/ffleurey/ThingML/issues/3

ffleurey commented 13 years ago

Actually, I think that this is pretty orthogonal. We can have messages with send and receive on both required and provided port. The semantics of a required port basically means that you cannot start the component before you have a binding and that the component on the other side has been started. It also says that bindings/channels can only exist between a required port and a provided port. This is aligned with Kevoree semantics I think.

brice-morin commented 13 years ago

I kind of agree.

But usually, for example in Kevoree, provided port = reception of messages. Required ports = emission of messages.

Moreover, if we have a received message on a required port, this would mean that we should wait that the component sending the messages on the other side is started before we start the component. Then the component could receive messages before it has been started... When there is no cycle, the receivers should ideally be started before the emitters. Otherwise, we could have some deadlocks (not in ThingML which is mostly asynchronous), or lose some messages if communication channels are flooded before the consumer can start, etc

2011/7/10 ffleurey reply@reply.github.com:

Actually, I think that this is pretty orthogonal. We can have messages with send and receive on both required and provided port. The semantics of a required port basically means that you cannot start the component before you have a binding and that the component on the other side has been started. It also says that bindings/channels can only exist between a required port and a provided port. This is aligned with Kevoree semantics I think.

Reply to this email directly or view it on GitHub: https://github.com/ffleurey/ThingML/issues/3#issuecomment-1542200

brice-morin commented 13 years ago

After a discussion with some of our new users, it appears that the double qualification provided/required VS sent/received is very confusing and counter intuitive. I'm OK to have bi-directional ports ie, ports with can send and receive message, but I am more and more convinced we should not have provided and required port. Rather I suggest to only have ports, which could be optional. An optional port means that the Thing can run even though this port is not bound. This is basically what you defined as a "receive" port: "The semantics of a required port basically means that you cannot start the component before you have a binding".