|
An InformationPacket (IP) is a structured chunk of data that is used in FlowBasedProgramming to contain data. It has a lifetime, from creation to destruction, and may only be owned by one FBP Process? at a time, or be in transit between processes. Is an IP required to be (or should it be) an immutable ValueObject? * I think IPs are more similar to ReferenceObjects. They could be made immutable so that any process that changes their state must create a new version and discard the old version. I can see advantages to this conceptually, but the overhead goes up significantly, and it would probably force one to implement some form of GarbageCollection. In FBP in general we have allowed IPs to flow from one process to another and to be explicitly discarded when no longer needed. This in turn allows the software to verify at run-time that every piece of data has been completely processed and disposed of. Quoting from http://www.jpaulmorrison.com/fbp/simpapp3.htm, "... each IP is individually tracked from the moment of creation to the time it is finally destroyed, and it cannot simply disappear, or be duplicated without some component issuing a specific command to do this. During an IP's transit through the system, it can only be owned by one process at a time, so there is no possibility of two processes modifying one IP at the same time. We in fact monitor this at execution time ..." * This in turn allows the software to verify at run-time that every piece of data has been completely processed and disposed of. Surely GarbageCollection is the antithesis of this, and yet I haven't seen anyone argue against GarbageCollection. Think of an important memo being sent from one person to another, or filed, or destroyed. Would you want it to suddenly disappear because nobody is looking at it?! Comments, anyone? --pm * What if a Memo can't be reached because it is either lost or that there are no more references pointing to it? [Since we seem to be saying the same thing, I have removed the 'but', and also changed 'ReferenceObjects?' to 'references'. --pm] Then the object, in effect, doesn't 'exist' anymore. So, if you deem a Memo important you must make sure that there are a lot of references pointing to it! Still, I do think GC becomes problematic in long-lived and distributed environments such as JiniTechnology or the LindaLanguage. Leasing objects and references with a special 'time-out' may be a nice solution and is somewhere in between GC and explicit disposal. --rvd * There are a pair of limericks that seem to address this point - I don't know who wrote them originally:
To which came the rejoinder:
So you need a God who will look after all objects to make sure they don't disappear... (BTW "quad" is short for "quadrangle") --pm * PS What is "object leasing"? IPs (or their handles) travel across inter-process connections in Stream?s, where the stream is produced and consumed asynchronously. Thus typically not all the Stream has to exist at the same moment in time, but it can still be regarded as a single entity, with well-definable attributes, such as "time of creation of first IP", "total number of IPs", etc. Stream?s may be subdivided into substreams by various types of signal IPs, one interesting type being a BracketIP?. IPs can also be linked into TreeIPs, where the root of the tree (or its handle) is what travels from process to process. In this case, non-root IPs are only owned indirectly by processes. Trees may be mapped onto structures of substreams, and vice versa. IPs resemble Linda's "tuples" (see LindaLanguage) in that they exist in a space of their own, like TupleSpace. However, unlike in Linda, these data objects are not retrieved associatively, but travel across inter-process connections. Therefore the "downstream" process knows when no more IPs will arrive. Also connections can be checked by the software to make sure that no IPs are still in transit. |
|
An InformationPacket (IP) is a structured chunk of data that is used in FlowBasedProgramming to contain data. It has a lifetime, from creation to destruction, and may only be owned by one FBP Process? at a time, or be in transit between processes. In JavaFBP, C#FBP and FlowBase (DavidBennett's C# implementation), a packet has a content which may be any object, and also may have attributes and chains attached to it. It also has a type, which must be one of: * NORMAL * OPEN (open bracket) * CLOSE (close bracket) In the case of OPEN and CLOSE, the contents will be a string denoting the name (see Fig. 12.7 in http://www.jpaulmorrison.com/fbp/tree.htm). Is an IP required to be (or should it be) an immutable ValueObject? * I think IPs are more similar to ReferenceObjects. They could be made immutable so that any process that changes their state must create a new version and discard the old version. I can see advantages to this conceptually, but the overhead goes up significantly, especially if working with TreeIPs, and it would probably force one to implement some form of GarbageCollection. In FBP in general we have allowed IPs to flow from one process to another and to be explicitly discarded when no longer needed. This in turn allows the software to verify at run-time that every piece of data has been completely processed and disposed of. Quoting from http://www.jpaulmorrison.com/fbp/simpapp3.htm, "... each IP is individually tracked from the moment of creation to the time it is finally destroyed, and it cannot simply disappear, or be duplicated without some component issuing a specific command to do this. During an IP's transit through the system, it can only be owned by one process at a time, so there is no possibility of two processes modifying one IP at the same time. We in fact monitor this at execution time ..." * This in turn allows the software to verify at run-time that every piece of data has been completely processed and disposed of. Surely GarbageCollection is the antithesis of this, and yet I haven't seen anyone argue against GarbageCollection. Think of an important memo being sent from one person to another, or filed, or destroyed. Would you want it to suddenly disappear because nobody is looking at it?! Comments, anyone? --pm * What if a Memo can't be reached because it is either lost or that there are no more references pointing to it? [Since we seem to be saying the same thing, I have removed the 'but', and also changed 'ReferenceObjects?' to 'references'. --pm] Then the object, in effect, doesn't 'exist' anymore. So, if you deem a Memo important you must make sure that there are a lot of references pointing to it! Still, I do think GC becomes problematic in long-lived and distributed environments such as JiniTechnology or the LindaLanguage. Leasing objects and references with a special 'time-out' may be a nice solution and is somewhere in between GC and explicit disposal. --rvd * There are a pair of limericks that seem to address this point - I don't know who wrote them originally:
To which came the rejoinder:
So you need a God who will look after all objects to make sure they don't disappear... (BTW "quad" is short for "quadrangle") --pm * PS What is "object leasing"? IPs (or their handles) travel across inter-process connections in Stream?s, where the stream is produced and consumed asynchronously. Thus typically not all the Stream has to exist at the same moment in time, but it can still be regarded as a single entity, with well-definable attributes, such as "time of creation of first IP", "total number of IPs", etc. Stream?s may be subdivided into substreams by various types of signal IPs, one interesting type being a BracketIP?. IPs can also be linked into TreeIPs, where the root of the tree (or its handle) is what travels from process to process. In this case, non-root IPs are only owned indirectly by processes. Trees may be mapped onto structures of substreams, and vice versa. IPs resemble Linda's "tuples" (see LindaLanguage) in that they exist in a space of their own, like TupleSpace. However, unlike in Linda, these data objects are not retrieved associatively, but travel across inter-process connections. Therefore the "downstream" process knows when no more IPs will arrive. Also connections can be checked by the software to make sure that no IPs are still in transit. |
In JavaFBP, C#FBP and FlowBase (DavidBennett's C# implementation), a packet has a content which may be any object, and also may have attributes and chains attached to it. It also has a type, which must be one of:
In the case of OPEN and CLOSE, the contents will be a string denoting the name (see Fig. 12.7 in http://www.jpaulmorrison.com/fbp/tree.htm).
Is an IP required to be (or should it be) an immutable ValueObject?
![[Home]](/wiki.gif)
There was a young man who said: "God,
I find it exceedingly odd
That this sycamore tree continues to be
When there's noone about in the quad."
To which came the rejoinder:
God answered: "It isn't so odd.
I am always about in the quad.
So this sycamore tree continues to be
Ever watched by, Yours Faithfully, God."
So you need a God who will look after all objects to make sure they don't disappear... (BTW "quad" is short for "quadrangle") --pm
IPs (or their handles) travel across inter-process connections in Stream?s, where the stream is produced and consumed asynchronously. Thus typically not all the Stream has to exist at the same moment in time, but it can still be regarded as a single entity, with well-definable attributes, such as "time of creation of first IP", "total number of IPs", etc.
Stream?s may be subdivided into substreams by various types of signal IPs, one interesting type being a BracketIP?.
IPs can also be linked into TreeIPs, where the root of the tree (or its handle) is what travels from process to process. In this case, non-root IPs are only owned indirectly by processes. Trees may be mapped onto structures of substreams, and vice versa.
IPs resemble Linda's "tuples" (see LindaLanguage) in that they exist in a space of their own, like TupleSpace. However, unlike in Linda, these data objects are not retrieved associatively, but travel across inter-process connections. Therefore the "downstream" process knows when no more IPs will arrive. Also connections can be checked by the software to make sure that no IPs are still in transit.