2011/3/29 Dave Cridland <dave@xxxxxxxxxxxx>
On Tue Mar 29 09:53:32 2011, Dave CROCKER wrote:COBOL, obviously.
I think that we should move more into that business.
I see no problem with actually specifying a language-specific API when
the WG involved has the skills to do a good job.
Wow. What is the list of languages we should work on? C, C++, _javascript_, Java, Python, ...?
Nah... INTERCAL or APL
More seriously, C has the benefits that an actual C API can often be rapidly pulled into another language, and if reasonably well designed can be remodelled for other languages easily.
Although I am not a C fan, I support the idea of (at list) a C-like syntax to specify the API because of its diffusion and also because, as you say, it is quite easy to translate a C-specified API to other languages.
Right, but that's in line (more or less) with what Sam went on to say in the paragraph you snipped:Another is to do more and better interoperability testing and let the API developers see their deficiencies and fix them. The benefit of this is that it moves the problem to the folks with the knowledge and incentives to work on it and it takes this very expensive specification task out of the IETF's critical path.
It'll often be sufficient to point out the shortcomings and specify what data needs to be accessed and (roughly) what form.
"When we do not, specifying abstract interfaces we expect platforms to provide still has significant value".
I'm all in favour of this.
Dave.
Let me add my +1e10 to the idea that we should (SHOULD?) specify at least a minimum API, at least at a very abstract level. I run in this type of problem recently. We were discussing about using DCCP for video streaming and it would have been useful to be able to access from the application the allowed rate estimated by DCCP. Missing a standard API, it is not clear if this is possible. Maybe the possibility depends on your software vendor, making portability a nightmare....
I would also like to add my thoughts (0.02) about how the API specification. You can have a very abstract description like
... the API for the Fast Overlay Obfuscation (FOO) protocol SHOULD allow the programmer to change the Maximum_Obfuscation_Rate, to select an Obfuscation_Procedure, ...
This is of course language independent and it describes the constraint that the API should verify. On the cons side, it could be that several vendors implement the abstract description in different way, giving rise to a new portability nightmare. The alternative to such an abstract description could be something like
... the API for the Fast Overlay Obfuscation (FOO) protocol SHOULD include at least the following functions
set_Maximum_Obfuscation_Rate (int rate);
set_Obfuscation_Procedure (int procedure_index);
This clearly depends on the chosen language. Moreover, if some of the data used in the API are quite complex (I am thinking, for example, to a X.500 certificate) a syntactically valid description of the API could be very large. On the other hand, one would have more uniformity between different implementations. I do not know which solution is the best one. I guess it will depend on the context.
--
Dave Cridland - mailto:dave@xxxxxxxxxxxx - xmpp:dwd@xxxxxxxxxxxxxxxxx
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf