2011/3/29 Dave Cridland <d...@cridland.net>
> On Tue Mar 29 09:53:32 2011, Dave CROCKER wrote:
>
>> 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, ...?
>>
>>
>> COBOL, obviously.
>
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.
> 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.
>>
>
> Right, but that's in line (more or less) with what Sam went on to say in
> the paragraph you snipped:
>
>
> "When we do not, specifying abstract interfaces we expect platforms to
> provide still has significant value".
>
> It'll often be sufficient to point out the shortcomings and specify what
> data needs to be accessed and (roughly) what form.
>
> 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:d...@cridland.net - xmpp:d...@dave.cridland.net
> - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
> - http://dave.cridland.net/
> Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
>
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
