End-to-end principle: Difference between revisions
Jump to navigation
Jump to search
Amwelladmin (talk | contribs) No edit summary |
Amwelladmin (talk | contribs) No edit summary |
||
| Line 20: | Line 20: | ||
*'''Third layer''': Say someone then operates a bus service on the road network. This is a third layer excellent for those who want to go whether the bus is going on the road network, but no good if you want to go somewhere else on the road network, let alone if you want to go elsewhere on the land. | *'''Third layer''': Say someone then operates a bus service on the road network. This is a third layer excellent for those who want to go whether the bus is going on the road network, but no good if you want to go somewhere else on the road network, let alone if you want to go elsewhere on the land. | ||
The classic example is of course the [[internet]] itself. At its most basic layer, it is a series of connected notes using the TCI/IP protocol and packet switching to which takes any type of data (text, video, audio etc) breaks it into tiny homogenous “packets” and sends them off across the network with an address, and the client at the receiving end reassembles them. There are all kinds of additional layers in it, be they walled gardens (Facebook etc) streaming services (Netflix), cloud servers and what not. Even as the fortunes of these services and gardens wax and wane (where are they now, AOL and MySpace) the un-owned internet grows ever stronger. | The classic example is of course the [[internet]] itself. At its most basic layer, it is a series of connected notes using the [[TCI/IP protocol]] and packet switching to which takes any type of data (text, video, audio etc) breaks it into tiny homogenous “packets” and sends them off across the network with an address, and the client at the receiving end reassembles them. There are all kinds of additional layers in it, be they walled gardens (Facebook etc) streaming services (Netflix), cloud servers and what not. Even as the fortunes of these services and gardens wax and wane (where are they now, AOL and MySpace) the un-owned internet grows ever stronger. | ||
===Consequences=== | ===Consequences=== | ||
| Line 29: | Line 29: | ||
*'''It’s agile''': Thus as use cases develop, the network develops organically to accommodate the new uses through the entrepreneurial development of the network. So the internet has adapted from messaging to webpages, to VOIP and videostreaming etc etc etc. | *'''It’s agile''': Thus as use cases develop, the network develops organically to accommodate the new uses through the entrepreneurial development of the network. So the internet has adapted from messaging to webpages, to VOIP and videostreaming etc etc etc. | ||
This applies in the design of all other kinds of multi-use systems, such as — for rather good example — a digital execution hub. There are a number of things you should not do when designing a network: | This applies in the design of all other kinds of multi-use systems, such as — for rather good example — a digital execution hub. There are a number of things you should not do when designing a network if you want to maximise its chances of success: | ||
*'''Teach to fish, do not give a fish''': Do not try to anticipate future uses. Acknowledge that the potential applications and use-cases | *'''Teach to fish, do not give a fish''': Do not try to anticipate future uses. Acknowledge that the potential applications and use-cases | ||
*'''Set it free''': Release all code. Make access free. If you try to meter it, extract rent or otherwise monetise basic access to the network, or stifle user’s attempts to build structures on the network, you will dissuade people from using the network at all. | |||
*'''Live with free-riders''': it is better to permit free riders than to charge entry to all. Free riders aren’t such a bad thing: mostly, they are ''not'' exclusively free-riders and their usage patters will give other users valuable data about what parts of the network are useful and which are not. | |||
*'''Bottom up, not top down''': Don’t design by committee. As far as possible allow — and require — clients to develop structures on the network that are useful ''to them''. The premise is that the basic layer of the network is a simple as possible: once established as a design it should not need maintenance, and users should contribute much of the hardware. | |||
{{sa}} | {{sa}} | ||
({{br|Code: Version 2.0}} | ({{br|Code: Version 2.0}} | ||
{{ref}} | {{ref}} | ||