Re: Call for volunteers for C/C++ API liaison manager

Thomas Nadeau <tnadeau@lucidvision.com> Thu, 01 May 2014 15:26 UTC

Return-Path: <tnadeau@lucidvision.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60D051A6F8D; Thu, 1 May 2014 08:26:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.553
X-Spam-Level:
X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rE7YrKf683ca; Thu, 1 May 2014 08:26:48 -0700 (PDT)
Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 00F761A6F8F; Thu, 1 May 2014 08:26:45 -0700 (PDT)
Received: from [192.168.1.112] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 5D64E278B90E; Thu, 1 May 2014 11:26:43 -0400 (EDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_70F2E130-E4BF-4913-8C6A-E35E10DDEA78"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
Subject: Re: Call for volunteers for C/C++ API liaison manager
From: Thomas Nadeau <tnadeau@lucidvision.com>
In-Reply-To: <536261F0.1070004@isi.edu>
Date: Thu, 1 May 2014 11:26:41 -0400
Message-Id: <F12396FD-1035-4530-948C-FBD02DF741D6@lucidvision.com>
References: <EB423B81-41F2-480D-B1EE-80E1753E1CDB@iab.org> <53618BDD.1080900@isi.edu> <368E668C-E60A-4D65-B3C6-F3CFCB66EBA7@lucidvision.com> <536261F0.1070004@isi.edu>
To: Joe Touch <touch@isi.edu>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/ypT7kuy0IxckYXsOorKdL7CQf08
Cc: IAB <iab@iab.org>, IETF <ietf@ietf.org>, IETF Announce <ietf-announce@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 May 2014 15:26:49 -0000

On May 1, 2014:11:02 AM, at 11:02 AM, Joe Touch <touch@isi.edu> wrote:

> 
> On 5/1/2014 5:12 AM, Thomas Nadeau wrote:
>> 
>> 	APIs are not that useful unless there is code behind them.
> 
> Ultimately, yes. But the code represents an instance of the API.

	That depends on your perspective. These days the code IS the API, in particular open source code. Standards bodies do not need to define the APIs; implementation communities do that already.  The IETF should probably stick to on-the-wire protocols.  

> The "application" layer actions in RFC793 - SEND, RECEIVE, CONNECT, LISTEN - are *not* the same as the Unix socket API; Unix sockets are one implementation of that interface.
> 
> > Are you proposing code that goes with those APIs?
> 
> Yes, just as I would propose code that implements a protocol. But I don't think either one is useful in the IETF except as an example - definitely never as a specification.
> 
>> Also the language that you do this in is important depending on the
>> area of applicability.
> 
> Just as much (or little) as the physical layer (802.11, ethernet, carrier pigeon) is important to IP.
> 
> > For instance, if these APIs are related to modern
>> applications, C is all but useless because its not used to build most of
>> those; you need Java/python/etc... for these cases.
> 
> If you don't have C, you often don't have scripted languages that are (often) compiled from C source code.
> 
> However, that depends on your compiler and the environment in which you develop your languages. That's important for language developers, but not the IETF (any more than we spec how to build pigeon coops).

	This is why I personally think this sort of effort would not be very useful; modern applications are simply not built this way any longer.

	--Tom