I find the term "protocol" confusing (in the terms of computer science that is). If the protocol is just a set of rules, wouldn't it be easier if we used the term "standard" instead (like in "HTTP standard")?
What’s the difference between the terms “protocol” and “standard”
standardsterminology
Related Solutions
Abstraction deals with simplification, indirection deals with location.
Abstraction is a mechanism that "hides" complicated details of a object in terms of simpler, easier to manipulate terms. In programming, a good example is the difference in details between machine code and the various tools for creating applications that are ultimately based on machine code. Consider creating a Windows Form application with the Visual Studio IDE. The IDE lets you think of the application in terms of easy-to-manipulate items in a What-You-See-Is-What-You-Get manner. The position of a screen widget is abstracted out to a visual location in a frame which you can change by dragging the widget around. Internally, the IDE manipulates the widget using another layer of abstraction such as a high level language (such as C#). C# itself is not manipulated using machine code, it is manipulated using a "Common Runtime Environment" which itself is an abstraction of a computer and operating system.
Indirection refers to making the location of an item transparent. If you know a web resource's URI, you can access the resource without knowing its precise location. You do not access the resource directly, instead you access through a channel that passes your request through a series of servers, applications and routers. Indirection may be considered to be a special type of abstraction where the location is abstracted.
Great Question.
It is important to distinguish between 'Development' and 'R&D.'
- Point 1
R&D = experimenting with ideas/technology that may never actually become a product.
Software Development = working on a product/service desired by a real customer.
- Point 2
R&D is all about developing new solutions for a specific problem domain. The end result of this endeavor is something that I call "research toys".
To be a software product, the research toy has to be completely re-implemented. Failure to do so will result in a product that appeals to an increasingly elite and erudite user base. The problem here is that this elite and erudite user base typically has no money to spend.
To be a successful, the software product must be a faithful re-implementation of the research toy, accessible and loved by the commodity user. To be truely remarkable, the software product must simultaneously appeal to the elite and erudite user.
- Point 3
Research implies scholarly or scientific inquiry and tends to be aimed at the greater good of an industry or society at large. Product development has different motivations and outcomes: it is driven by the potential for profit. The state of product development is healthy. The state of lighting research is not.
We need a collective commitment to the greater good to answer such questions. But this is not just philanthropy; the answer would address a practical goal. Light sources that are spectrally tuned to the visual system will be more sustainable. They will use less energy by generating their output in regions of the spectrum where the visual system responds most strongly, resulting in better seeing for building users. This example reinforces the difference between research and product development.
- Point 4
All development of new products to be R&D. I think some of you are confusing pure, abstract science with R&D. They aren't the same. R&D can be very product oriented. Scientists may be looking for a vaccine to cure AIDs. That is a very specific task to create a product to sell and it is certainly R&D and not just guys sitting around messing about with whatever they feel like.
- Point 5
R&D in the technical world = finding ways to do something interesting or important, using known techniques and technology as a starting point.
Software development = finding ways to do something interesting or important, using known techniques and technology as a starting point.
- Point 6
Virtually all software development is the D part of R&D. Some times, there are very little R in Software 'R&D'. Some times, there are pretty large R in Software 'R&D'.
It depends on several measurement. For example,
Managing software development for various sized companies, R&D takes on different meanings depending on the size of the company, customer base, etc.
In a small software company, with only a hand full of employees, the line between R&D software and Production software is usually very small. What one day is a software R&D project, may the next day be shipping as production software to customers.
As software companies grow, and they have one or more production software lines, they tend to create greater separation between R&D software projects and Production software products (for obvious reasons). This R&D gap is typically created to create greater diversification in their software products for tomorrow, while allowing the production software development to continue to produce today.
This is not to say that the production software products won't get innovative new features. The production software developers are typically just as "sharp" as the R&D developers. In fact, at one company, we had an enrichment program that allowed production software developers to rotate in and out of R&D projects. This not only added fresh brain power to the R&D teams, but in many cases, the production developers came back with new ideas on producing better production level software.
- Point 7
D = "knowing where you want to be at the end", and R is because "at the beginning of the project, you don't know what will be required to get there"
- Point 8
R&D are the lucky folks who get to do anything they want without accountability.
Good research/resource on this topic :
Best Answer
Not all protocols are standards (some are proprietary). Not all standards are protocols (some govern other layers than communcation).