I have been so lazy: I cannot believe it.
What is happening?
Well many new findings: and discussions: and I think we shall have a roadmap soon.
But in this blog I will proceed one by one, illustrating each construct through examples.
Because of the difficulty and subtlety of our goal, because of the beauty and simplicity we want, because of the coverage of the descriptive tools we are making, it is best we proceed one by one.
Since interactions are everywhere and since many people seem to be approaching this idea from many angles --- from the observation that transaction is too restrictive for huge systems; from the observation that sharing and using financial protocols together is really beneficial for users; from the obvervation that we should share the infrastructure for message passing since in business we deal with messages not call-return; and from the need to describe applications and even operating systems as concurrent modules communicating with each other --- it does seem a good paradigm for describing interactions is being desired.
A paradigm --- or abstraction: we surely need a good abstraction or abstractions to articulate, model and describe, as well as building such interactional systems. And tools. And rules. And of course good implementation ideas. Everything. But we need some abstractions to start from.
A conversation is only one of possible such abstractions, a modest proposal from us and some of our friends. We recall it was once named session: it was also named contract; it was also named protocol. All these names give one side of this idea. Whatever it is there seems to be something which may be usable here: something concretely usable, at least for some purposes, for scribbling interactions nicely and clearly. Scribble is an experiment to create a new piece of a descriptive tool (or a family of tools) based on this abstraction.
It is for scribbling: so it should work with a simple setting of pencil and paper: but of course it will make the best of all software tools and artifacts and infrastructure we can avail.
And starting from a smallest conversation which is just one-time interaction done alone, and reaching a conversation which consists of 10 million messages or even more (in the large scale this is a norm in international financial protocols such as SWIFT; and in the minuscule level this is again a norm in on-chip interconnect which easily allows 1 million message passing in a second), we have many conversations and its phenomenology (or zoology if you like) never ceases to surprise this one of the humble designers of scribble. These are what we should capture and I now realise it is a fascinating journey we are now going through.
Today I finish here: I will continue with the choice example in the next blog. There are some who have new examples --- which we may be introduce when here is a chance. Let's also treat it here. Scribble is about a conversation so it is not surprising we are starting have several conversations. And conversations are never just one way: ideas are merged and interwoven and will lead to further budding ideas. This blog is just a record of such conversations surrounding scribble.
Friday 21 September 2007
Saturday 8 September 2007
channel or port: a problem of English
I have not posted for some time: during that time I thought a bit about difference between port and channel starting from a chat with Matthew which let me recall what Gary cautioned me initially. For a channel one can read as follows from wikipedia:
Perhaps more understandably, one may also say a name in the pi-calculus is a name of a channel: and if we regard that channel's input capability is fixed to some process then it becomes a port of that process.
All in all the main point is we can use "to" if what we are declarting is indeed a channel, as we did above. Alternatively if it is to be a port which we wish to declare --- as the prefix "at" suggests --- then we may as well write:
But if we have two participants which share a port to receive how does it look like?
So may we come back to channel?
And if "from" is not specified then it means (in principle) anybody can use that channel for sending his or her message as far as a protocol as a whole is well-formed. Here "well-formed" means we do not have a message mix-up as we have seen in Example (1) Asynchrony a fortnight ago (which is here) (by the way having multiple senders may not be so bad in comparison, this time the medium is something like having multiple inlets and a single outlet: we can visualise it as a filter: and of course we can also have a multicast channel too in which a message is always copied to each outlet).
OK so perhaps a channel is still a good idea and we are going to use "to" instead of "at" or "@" when we declare the receiver(s) of a channel: that looks to me more and more natural. But if you have any observations please let us know!
Channel in communications refers to the medium used to convey information from a sender (or transmitter) to a receiver.Well this is what Gary and Matthew told me: a channel is a path between two endpoints rather than a place at which we send some datum. The latter is called port:
http://en.wikipedia.org/wiki/Channel_%28communications%29
A port is an interface between the computer and other computers or devices. Physically, a port is a specialized outlet on a piece of equipment to which a plug or cable connects .... (etc.)
http://en.wikipedia.org/wiki/Computer_port_%28hardware%29So a channel is a path whereas a port is an interface; and our declaration syntax:
channel chWorld @ World;looks somewhat strange since a channel cannot be located at an endpoint World: and I can now see why Gary suggested I should use the term "to" as in:
channel chWorld to World;but at that point I did not precisely see what he was getting at. And then Matthew said a channel is like English channel and it is not a place which you throw a message at and well it is quite right. And I realised a channel in the pi-calculus is a name for a channel and as such it is also a port since it is also an interface: it is a name. A name can be given to a path/medium (even perhaps a path which can be shared by many inputs and many outputs) or to a port and in such a basic formalism as pi all these different notions come out by different usage of names (just as objects and functions and streams and all that can be represented by specific ways of name passing in this calculus).
Perhaps more understandably, one may also say a name in the pi-calculus is a name of a channel: and if we regard that channel's input capability is fixed to some process then it becomes a port of that process.
All in all the main point is we can use "to" if what we are declarting is indeed a channel, as we did above. Alternatively if it is to be a port which we wish to declare --- as the prefix "at" suggests --- then we may as well write:
Then we can write:port pWorld @ World;
pWorld.greetings(string) from You to World;which may not be so bad after all.
But if we have two participants which share a port to receive how does it look like?
port pWorld @ {World1, World2};So pWorld is a port --- an entry point --- in which a message may arrive, to be received by either World1 or World2.Well this sounds slightly magical --- how can a port be placed in two disparate locations? --- and in fact it now sounds more like a channel.....
So may we come back to channel?
channel chWorld to {World1, World2};Well this makes a better sense: chWorld is the name of a medium, a path, through which a message will be passed to one of these participants. We did extend the idea of "one sender one receiver" idea above, but a communication medium in computing can be more versatile than geographical ones and indeed this generality is a matter-of-fact in the pi-calculus (note however a receiver is almost always unique: we consider a single receiver a default and perhaps even prohibit multiple receivers in some class of applications).
And if "from" is not specified then it means (in principle) anybody can use that channel for sending his or her message as far as a protocol as a whole is well-formed. Here "well-formed" means we do not have a message mix-up as we have seen in Example (1) Asynchrony a fortnight ago (which is here) (by the way having multiple senders may not be so bad in comparison, this time the medium is something like having multiple inlets and a single outlet: we can visualise it as a filter: and of course we can also have a multicast channel too in which a message is always copied to each outlet).
OK so perhaps a channel is still a good idea and we are going to use "to" instead of "at" or "@" when we declare the receiver(s) of a channel: that looks to me more and more natural. But if you have any observations please let us know!
Monday 3 September 2007
Example (11): one by one
I admit what I wrote yesterday was an off-topic --- something was complete so I got slightly relieved.
Anyway we prepare for auction protocols: now an auction has a lot of constructs in it (unicasting, multicasting, loop, perhaps a global escape, choice, ...) so perhaps it's a good idea to introduce each of the basic constructs one by one. Our simplest protocol so far is one for the "hello world":
Recall @ indicates the locatedness:
When a channel is declared, it will not be bound to anything later: a declared channel is entirely a logical entity inside a conversation (if you are familiar with the pi-calculus it corresponds to declaring a channel with "new"). This is like a method name (selector) is a pure name and is logically independent from any external entities. Or perhaps better it is like a locally declared variable which gets generated when a method is called and discarded when the method returns. So declaring a channel as above means specifying this channel is local to a conversation which will materialise this protocol.
This is subtlety of channel, how it is different from participants, and that which is important when we consider a protocol which allows the description of unbounded conversation structure.
Once we have everything declared we can have an interaction --- we formally call this interaction signature as distinct from conversation signature, but let's be simple --- which is:
to World from You if you like. Sometimes uniformity does pay for a quick understanding though.
To leave no stones unturned let's see what this
But what is the use of this operator name? In OOPL we had a method dispatch table and we need to go to an appropriate code: but how does the operator name have use in interaction? Just as the mechanism of dynamics in OOPL, logically or as embodied in the design of VM (in the sense of JVM, not VM as in Xen), this operator name is closely tied to a key mechanism of conversation-based interaction which is a finite state automata which governs conversation behaviour. In brief an operator name serves as a transition label in FSA. So when a state in a FSA has several choices it is different labels which are used for this purpose. Of course logically (just like method names) it serves as a way to indicate what this message is about.
We shall come back to this point later. Here we note there is a simple way to go without an operator name and it is using a type name instead of an operator name, like (presenting the whole interaction):
To this topic we shall also come back later. I think this is enough as detailed examination of these basic constructs.
My original purpose was to introduce the next most basic constructs, sequencing and choice, after I briefly examined what we introduced already, but this prelude took long: I will continue with sequencing and choice in a new post, perhaps a couple of hours later.
Anyway we prepare for auction protocols: now an auction has a lot of constructs in it (unicasting, multicasting, loop, perhaps a global escape, choice, ...) so perhaps it's a good idea to introduce each of the basic constructs one by one. Our simplest protocol so far is one for the "hello world":
protocol GreetWorld {where we declare this is the protocol, we declare its name (GreetWorld), then we declare participants we shall use as pure names so that models and programs can bind later, and we declare a channel we use.
participant You, World;
channel chWorld @ World;
chWorld.greetings(string) from You to World;
}
Recall @ indicates the locatedness:
channel chWorld @ World;says that (1) we use the channel chWorld and that channel is located at World: World is the participant who can receive messages from this channel.
When a channel is declared, it will not be bound to anything later: a declared channel is entirely a logical entity inside a conversation (if you are familiar with the pi-calculus it corresponds to declaring a channel with "new"). This is like a method name (selector) is a pure name and is logically independent from any external entities. Or perhaps better it is like a locally declared variable which gets generated when a method is called and discarded when the method returns. So declaring a channel as above means specifying this channel is local to a conversation which will materialise this protocol.
This is subtlety of channel, how it is different from participants, and that which is important when we consider a protocol which allows the description of unbounded conversation structure.
Once we have everything declared we can have an interaction --- we formally call this interaction signature as distinct from conversation signature, but let's be simple --- which is:
chWorld.greetings(string) from You to World;The interaction says You (in fact somebody who is bound to You) will send a greeting to World via the channel chWorld. As we have discussed, we are assuming asynchronous messaging which will travel through some network infrastructure --- that expanse. The phrases such as from You and to World can be changed heir positions so we can say
to World from You if you like. Sometimes uniformity does pay for a quick understanding though.
To leave no stones unturned let's see what this
greetings(string)which is the message You will send to World. Here greetings is an operator name --- or a selector, quite like a method name --- and string is its argument type. Like method names, operator names are internal to a protocol. So a message (logically) in this interaction will/should consist of an envelope which is this operator name and its content which is a string.
But what is the use of this operator name? In OOPL we had a method dispatch table and we need to go to an appropriate code: but how does the operator name have use in interaction? Just as the mechanism of dynamics in OOPL, logically or as embodied in the design of VM (in the sense of JVM, not VM as in Xen), this operator name is closely tied to a key mechanism of conversation-based interaction which is a finite state automata which governs conversation behaviour. In brief an operator name serves as a transition label in FSA. So when a state in a FSA has several choices it is different labels which are used for this purpose. Of course logically (just like method names) it serves as a way to indicate what this message is about.
We shall come back to this point later. Here we note there is a simple way to go without an operator name and it is using a type name instead of an operator name, like (presenting the whole interaction):
chWorld.string from You to World;where we specify only the type, not a selector. This works well especially when you are sending a specific message type as in:
chWorld.Greetings from You to World;In such a case the name Greetingsserves as both the operator name and the message content.
To this topic we shall also come back later. I think this is enough as detailed examination of these basic constructs.
My original purpose was to introduce the next most basic constructs, sequencing and choice, after I briefly examined what we introduced already, but this prelude took long: I will continue with sequencing and choice in a new post, perhaps a couple of hours later.