How do you create protocols to exchange between different providers and consumers without blocking innovation or becoming anarchy?
Bret argues that protocols can be proprietary (created by an entity) but should be published. Protocols can also be based on other proprietary protocol and standard object provided by the platform (e.g Text, Keyword, Location, etc.).
If a new provider wants to provide its protocol, it can provide both the previous mainstream protocol and his own. If his own protocol provides sufficient advantages, consumers can start using it.
http://worrydream.com/MagicInk/#p373 by Bret Victor
Protocol. The last problem I will consider here is the political issue of protocol creation. Just what is a
Restaurantobject, and who decides that? Standards, especially premature ones, stifle invention and progress, but anarchy results in incompatibility. It may be possible to address this problem through namespacing and published proprietary protocols.To answer the above question, there is no Restaurant object. Instead,
EpicurioCityproduces acom.EpicurioCity.Restaurant object[1], whose protocol is defined and managed byEpicurioCity.com. This proprietary object can be composed of other proprietary objects, as well as some standard objects defined by the platform, such as Text, Keyword, and Location. Note that this proprietary Restaurant is not hindered from showing up on the map, since the map will accept anything with a Location (and presumably some other standard properties such as a name and description)[2]. A restaurant guide view, on the other hand, would be written to take advantage of the extra information thatcom.EpicurioCity.Restaurantoffers—ratings, reviews, and such.[1] Or however namespacing is spelled in the implementation language.
[2] In object-oriented terminology,
com.EpicurioCity.Restaurantconforms to the Mappable interface, and the map requests Mappable objects. However, this “interface” can be very informal, and even unknown to the Restaurant. If the Restaurant happens to define enough standard properties, it can be mapped.When another provider,
CuisineCousins.com, develops a competing restaurant translator, it can follow EpicurioCity’s published protocol and producecom.EpicurioCity.Restaurantobjects. This makes their new translator immediately compatible with existing views. Meanwhile, the translator can simultaneously offer their own objects, such as acom.CuisineCousins.Eatery, with whatever advantages over EpicurioCity’s protocol. View providers can then update their software to also accept CuisineCousins’s protocol, if CuisineCousins offers a compelling enough advantage.If a de facto standard emerges and stabilizes, it might eventually get canonized as the official Restaurant object. Even then, though, providers will be able to add proprietary namespaced extensions to it.