Push, Pull, and...?

Are you thinking like in a CAN-BUS system of communication between sending and recieving units like in an automobile or a farm tractor?

Well not specifically, just a very general sense of the terms. Really just any form of communications between two systems.

If "A" has no choice, it will pull. If there are instructions for "A" to pull only when it needs the "whatever," the system remains in stasis: fatal error. In other words, "B" will be pushing a rope up a hill. If this discussion turns philosophical, more terms need to be defined, and cases need to be delineated.

Hmm, so you're saying that in the situation where "System B pushes data to System A", the same can be said: "System A pulls the data from System B"

So, according to your definition, push/pull relations are only based on the direction of data flow? And, the difference in the two situations mentioned right above are only different because of different frames of reference (and the syntax to follow it). AND, your definition does not take into consideration whether the systems had a 'hand shake' before data flow started?

Here, then, is where the real discussion begins. Did "A" request to give or to receive? Did "B" agree to the relationship of being the giver or the receiver? Is there a moderator between the two? The handshake can be seen as the moderator which gives instructions to both "A" and "B." In this case, an outside agency decides who will push and who will pull. If one does not have instructions to push, the other cannot pull, and the other way around. Think of a man pushing a cart while another is pushing it from the other end. If both agree that the one behind is to push while the one in front is to pull, then the information to both is correct. That information has to come from the moderator (or, the handshake). Indeed, an agreement has to be reached before an outcome can be predicted: that is, the end desired. In this case, you're right in assessing that syntax is critical. A second definition, therefore, that has to be clarified is whether "A" or "B" can act alone. Certainly, this last concern enters the domain of the Koan.

To answer your questions:

Did "A" request to give or to receive?

• System A did not request to receive the data. System B just forced it to System A.

Did "B" agree to the relationship of being the giver or the receiver?

• Not quite sure what you meant in this question. But, B is not necessarily exclusively a giver or receiver system, this example, both systems could be both a giver and a receiver.

Is there a moderator between the two?

• No moderator between the two. Only very basic system-to-system connection, with no limitations based on certain 'roles' (either a giver or receiving) for each system.
  

Thanks for the input on the cart pushing example. Let me try to give another example though.

Let's say system Foo has expense reports for a company. On a weekly basis, Foo pushes the expense report data to system DataBase, which happens to be the enterprise database containing all of the company's records. DataBase simply stores data as it receives it, and therefore, we can assume it takes on no other roles. At the end of the week, Foo pushes the week's data to DataBase.

Now, the underlined section is 100% right (if there are concerns, I will start to really question how much I actually know about technology ). BUT, how would the DataBase system look at the data transaction? *Would it be appropriate to say "DataBase pulls from Foo", even though DataBase never sends out a request for the data? *

Whenever I hear the term 'pulling', I think of what you said J-Rod, an member acting on something (data in this case, a cart in your example) and bringing that thing closer to itself, which implies an active state of action from the source. But DataBase just happens to be idle and all suddenly receives this data from Foo without prior knowledge; it had no active action in the transaction. So Foo would be the guy pushing the cart, DataBase would be the guy laying on the ground, about to get hit by the cart. I hope that makes sense . Thoughts?

There's client-server, master/slave, peer-to-peer and shared storage. (I'm not familiar with a more commonly accepted term for the latter.) I can't think of any other arrangement. There's "gray" between the arrangements. Before a server fulfills a client's request, it may request identification or authorization. A P2P device may function exclusively as a server to the other, and either side might play the role of master or slave, or switch around as needed.

In a shared storage arrangement, both sides write and read data to/from the same medium. Some mechanism is needed to prevent collisions (writing to the same location at the same time), and it's often nice to be notified of updates, but it otherwise works wonderfully in appropriate roles.

I'm thinking in simplistic terms here and am attempting to re-define the transactions between the 2 systems, named FOO & BAR:

• PUSH: FOO sends data to BAR. "FOO pushes to BAR";
• PULL: FOO requests data from BAR. "FOO pulls data from BAR" (during the transaction, naturally, a PUSH from BAR occurs, but let's ignore that for the moment);
• PULSH: FOO sends data to BAR. BAR receives data and also pushes data to FOO. "FOO and BAR shares data and updates each other simultaneously".

Assumptions:

• standard handshake before each transaction;
• standard log-off and link-off after each transaction;
• all transactions are automatic as programmed.

so you see that I've entirely changed the definition according to which system initiates the transaction. this is the key word. "pulling" is not exactly synonymous to "extracting", only similar. IOW, the initiating system PULLS only after getting an approval for the REQUEST to pull. Extracting does not require authorization.

in plain terms, PUSH happens when the initiating system sends out data.

a PULL happens when the initiating system requests for the data.

a PULSH happens when a PUSH or PULL is taking place, but both systems are updated in the process.

just 2 cents from an antiquated systems man.