Sandman
In article <ej3d99tgutrdd23le9qt2dvflsotcg1lur@4ax.com>, Eric Stevens <eric.stevens@sum.co.nz>wrote:

-- if (isset($backup_destination)){ exec("/bin/cp -R /home/$USER /mnt/$backup_destination"); } else { $backup_destination = prompt("Where do you want to backup to?"); } --

Few, if any, developers would call this a protocol. It's just conditional code. And I fear that nospam's suspicion was correct, you're way out of your league here because you're ignorant about the technical nature of these things. Maybe "protocol" is your way to make sense, in your head, for a series of steps taken by the software that you don't understand how it is done? No shame in that, you're in good company if you know nothing about the tech trivia of computers.

Eric Stevens
You should think in terms of a black box.

Sandman
Why?

Eric Stevens
The protocol is an external set of requirements which determines what the black box is to do.

Sandman
What "black box"?

Eric Stevens
The program governs what goes on inside the black box which enables it to meet the externally imposed requirements of the protocol.

Sandman
This looks like yet another laymen's method to put words to what he doesn't understand.

I *am* a programmer, so I know very well how programs work internally, and they're not "black boxes" and they're not "protocols".

Eric Stevens
Note: The black box does not have to be a single box: it can include an operator. It can even be a building crammed with staff and computers. For the purpose of the discussion it defines a boundary around whatever it is that is intended to satisfy the requirements of the protocol.

Sandman
This doesn't make much sense on its own, and even less sense in conjunction with the topic under discussion.