Information Packet

A chunk of structured data in FlowBasedProgramming (FBP). An Information Packet (IP) has a definite lifetime - it is created at some point in time, by an asynchronous component (process), and destroyed at some later point, usually by a different component (process). In all implementations of FBP, Information Packets belong to classes which specify their attributes. Obviously in an OO implementation of FBP such as JavaFBP, this class can also have methods associated with it.

The metaphor here is of a memo being sent from one person to another, and then on to another, until it is eventually filed or destroyed. The FBP philosophy is to keep track of who owns these objects, and where they are in the network, so that the application designer can verify that all data objects are accounted for, both during the design process, and at run-time. I have called this an "accountant's view" of the universe, which seems antithetical to the GC concept. Comments, anyone?

See also http://www.jpaulmorrison.com/cgi-bin/wiki.pl?InformationPacket

• Paul: I'm looking forward to discussing this when we meet. A couple of preliminary points:
  • Must (by your definition) the Information Packet have a definite lifetime and be destroyed? My work to date with data differentiates three types:
    • Static (e.g. Date of Birth, which will never change),
    • Transient (e.g. a residential address which is generally a temporary join between my Name and the Municipal address at which I currently reside) and
    • Dynamic (e.g. my Bank balance, which goes up and down like a yo-yo and is just a snapshot of the cash component of my Assets) of data.
  • Data Structures in my experience, are generally constructs of 'atomic fields' (e.g. there is an ISO standard for credit (and now, debit) cards that defines those with a leading 3 as AMEX, 4 as Visa and 5 as Mastercard. Extending the Mastercard case, the second digit defines the length of the Issuer field, which then defines the Issuer. Hence 519... becomes a Mastercard issued by the BankOfMontreal. etc. for the rest of the 16 digits.) This same type of data structuring is evident in Canadian Postal Codes with their FSA-LDU structures that generally define a block face (one side of a street, between two intersections) or in telco's NPA-NNX (Area code, Exchange). I see these data structures as data atoms that make up information packets since they are components of the Information they present.
• We can, of course, agree that the scope of your definition is specific to FBP and that my considerations are therefore out of scope, but I think there may be merit in trying to rationalise our thoughts. -- HansWobbe.

As we discussed, your comments about data concern the types of data items, and I have no disagreement with them. In our experience with FBP, we have found that most data, as you say, is grouped into structures that ideally describe objects or entities in the real world, e.g. a person, a house, an account, etc. You are right that the individual data items may themselves have a finer structure, as e.g. dates. Data is fractal! Now imagine the data about a person, say, being extracted from a database, being modified as it flows through an FBP network, and arriving back on the database some time later. FBP InformationPackets (IPs) relate to the data as it flows in high-speed memory (what we used to call "core"!). Since you can have more complex structures of IPs (e.g. TreeIPs - see http://www.jpaulmorrison.com/cgi-bin/wiki.pl?TreeIP), you may have to linearize them to store them on a medium (like Java 'serialize').

This reminded me of something: data may be fractal, but its attributes may be different at different levels. On an OO-based project I observed, the designers realized that they needed to specify an attribute like "read for update" (a database concept) when accessing records on a database, so they decided they needed it on every object, including ones representing individual fields within records!

If you look at the 3rd diagram in http://www.jpaulmorrison.com/cgi-bin/wiki.pl?DrawFlow, you'll see the IPs doing a lot of flowing (across the lines in the diagrams), while the data records are being extracted from and returned to the process labelled MCBSIM, which handles customer information. MCBSIM's job is to turn data records into IPs and back again. See also the comment immediately preceding the diagram. --PaulMorrison