NEW-PROTOCOL: document what needs to be done to add one #6263
Conversation
bagder
force-pushed
the
bagder/new-protocol
branch
from
2b46c79
to
bcfb18f
Compare
|
One thing missing is a discusson on the significance of a protocol. Just
because it can be shoehorned into a URL syntax doesn't mean it should be
included in curl, if it's only used by a total of 3 people in the world, for
example. This document would also be a good place to mention that adding a
protocol involves additional work for curl maintainers from that point forward
into (potentially) infinity, a demand that should not be taken lightly. If we
can come up with hard figures on the potential number of users of a protocol,
we should add those. e.g. Are there even 100 people in the world still using
dict? Are there 500 still using gopher? Those two are at the low end of what
might be acceptable (they might below the bar if it were up to me). Or, maybe
figures on the minimum number of independent servers in the world running a
protocol would be easier to quantify.
|
|
I hear you, but that's a tough one to put into words. How about adding a small section like this? Wide and public useThe protocol shall already be used or have an expectation of getting used widely. Experimental protocols are better off worked on in experiments first, to prove themselves before they are adopted by curl. |
bagder
force-pushed
the
bagder/new-protocol
branch
from
5a51fc3
to
203d93a
Compare
| ## Documentation | ||
|
|
||
| We cannot assume that users are particularly familiar with specific details | ||
| and peculiarities of the protocol. It needs documentation. |
There was a problem hiding this comment.
On top of the curl documentation for the protocol, there should IMO be published documentation of the protocol itself licensed in a way which is freely available without an NDA etc.
There was a problem hiding this comment.
I'll add something about that!
|
|
||
| The protocol shall already be used or have an expectation of getting used | ||
| widely. Experimental protocols are better off worked on in experiments first, | ||
| to prove themselves before they are adopted by curl. |
There was a problem hiding this comment.
There should be at least one maintained server implementation which is in a (non-alpha/beta) production release?
There was a problem hiding this comment.
That would rule out early work on HTTP/3, if we would consider that a "new protocol". I added that "expectation" thing with protocols like that in mind.
My only concern with writing too many "shoulds" is that people will single out individual ones and use those as "see, they don't want support for our protocol because..." when we rather want to judge a new protocol based on "the full picture" and not throw anything out simply because maybe strictly speaking they don't fulfill an individual "should" mentioned in this document.
| @@ -74,6 +74,7 @@ EXTRA_DIST = \ | |||
| KNOWN_BUGS \ | |||
| MAIL-ETIQUETTE \ | |||
| MQTT.md \ | |||
| NEW-PROTOCOL.md \ | |||
There was a problem hiding this comment.
Curiosity killed the cat, why do we use all-caps for (most) documentation filenames? Legacy?
There was a problem hiding this comment.
Plain legacy and old habits... maybe I should rather break that off right now and do lower case here!
No description provided.