I think you missed the point. Sure, you need only to sip from the fire hose to finally quench your thirst, but that wastes a lot of water.
Where TCP acks and controls flow on every single packet, which also must be received by the sender in order, a protocol like this can occasionally send back a report on what kind and how many packets it is receiving (fragmented, packet loss due to bandwith, packet loss due to congestion).
Summary (and using more recent terminology): Web services that expose more new and unique code are more likely to expose bugs. RPCs, SOAP, and CGIs all encourage developers to write more exposed code by making that style easier to do.
One better alternative is to be more data-driven (some would say "functional", as in "functional programming"), so that you only expose data (via a standard server which would typically be more mature, heavily reviewed code).
Alas, that's an entirely different way of thinking that most people are not used to, since it flies in the face of "normal procedural or OO programming" that happens on the desktop. Some examples, though, are Linda Systems (TupleSpaces), REST (the traditional WWW architecture), and even P2P to a large extent.
[This doesn't have to wait for money to start, but $$$$$ would sure kickstart a project like this.]
The open source community, especially within the last few years of massive development, is in serious need of code merging.
I'm not talking about the big projects that have obviously different design goals, but so many of the little projects that have mostly overlapping features.
The project would start off working with Freshmeat to find projects that could be merged. Possibilities include command line utilities, taking GUI apps and creating a shared library of the core functionality, and taking language-specific libraries, converting them to C/C++/Obj-C, and rebinding them back to multiple languages.
Based on the list of projects, the code-reuse project can then begin coming up with tips and techniques for merging projects (both source and community), getting the various developers talking to each other, and participating in the merge effort.
Hiring a small team (3-10) of professional documenters for a year would benefit the open source community immensely.
Their mission would be to find or solicit mid-level to large projects that are past the alpha design stage, interview the lead developers to gain enough detail to write an 80% user and design documents, and hand it back to the project for normal, on-going development.
The main benefit is to have someone skilled in writing "lead" the development of the documentation for a short period.
PkgMaker is a tool I've written that can build packages for Solaris, HP-UX, binary tars, and RedHat RPMs. It uses a very simple model and can be easily extended for other package managers.
In writing PkgMaker I came to the same basic conclusions as Jeff did: adding a small amount of packaging information to a project's source would go a long way towards making packages easier.
Architecture is best done by a small number of people designing with as many components as possible (Cathedral style) whereas refinement and implementation is best done by a large body of developers (Bazaar style).
Mozilla is one of the best examples of mixing the two styles successfully, but they definitely need more developers helping in the Bazaar.
Slashdot Mirror
Yes, most PRT systems will take a bicycle or two so a Segway or two should fit as well.
The most comprehensive info on PRT is available at Jerry Schneider's Innovative Transportation Technologies site in the section on Personal Rapid Transit (PRT). The site has a much broader scope and compares PRT with several other systems as well.
I think you missed the point. Sure, you need only to sip from the fire hose to finally quench your thirst, but that wastes a lot of water.
Where TCP acks and controls flow on every single packet, which also must be received by the sender in order, a protocol like this can occasionally send back a report on what kind and how many packets it is receiving (fragmented, packet loss due to bandwith, packet loss due to congestion).
I wrote "Web RPCs Considered Harmful" that briefly addresses the security issue.
Summary (and using more recent terminology): Web services that expose more new and unique code are more likely to expose bugs. RPCs, SOAP, and CGIs all encourage developers to write more exposed code by making that style easier to do.
One better alternative is to be more data-driven (some would say "functional", as in "functional programming"), so that you only expose data (via a standard server which would typically be more mature, heavily reviewed code).
Alas, that's an entirely different way of thinking that most people are not used to, since it flies in the face of "normal procedural or OO programming" that happens on the desktop. Some examples, though, are Linda Systems (TupleSpaces), REST (the traditional WWW architecture), and even P2P to a large extent.
[This doesn't have to wait for money to start, but $$$$$ would sure kickstart a project like this.]
The open source community, especially within the last few years of massive development, is in serious need of code merging.
I'm not talking about the big projects that have obviously different design goals, but so many of the little projects that have mostly overlapping features.
The project would start off working with Freshmeat to find projects that could be merged. Possibilities include command line utilities, taking GUI apps and creating a shared library of the core functionality, and taking language-specific libraries, converting them to C/C++/Obj-C, and rebinding them back to multiple languages.
Based on the list of projects, the code-reuse project can then begin coming up with tips and techniques for merging projects (both source and community), getting the various developers talking to each other, and participating in the merge effort.
I'd sign up to work on this project.
Hiring a small team (3-10) of professional documenters for a year would benefit the open source community immensely.
Their mission would be to find or solicit mid-level to large projects that are past the alpha design stage, interview the lead developers to gain enough detail to write an 80% user and design documents, and hand it back to the project for normal, on-going development.
The main benefit is to have someone skilled in writing "lead" the development of the documentation for a short period.
PkgMaker is a tool I've written that can build packages for Solaris, HP-UX, binary tars, and RedHat RPMs. It uses a very simple model and can be easily extended for other package managers.
In writing PkgMaker I came to the same basic conclusions as Jeff did: adding a small amount of packaging information to a project's source would go a long way towards making packages easier.
Architecture is best done by a small number of people designing with as many components as possible (Cathedral style) whereas refinement and implementation is best done by a large body of developers (Bazaar style).
Mozilla is one of the best examples of mixing the two styles successfully, but they definitely need more developers helping in the Bazaar.