Subject: Re: (ngtrans) "Bump-in-the API" idea

From: Erik Nordmark <[email-masked]>
Date: Mon, 12 Jul 1999 07:45:51 +0-200

>But private customer in-house apps and then ISV apps are a different
>story.  

Those are the ones I'm particularly concerned about.

But the trick is to at some level be able to tell two different stories:
 To the developpers/ISVs: port to the new API
 To those trying to deploy: If you have applications that aren't ported
 first try to convice the developper to port them, and if this fails
 or takes too long, use a bump-in-foo approach to try to get the application
 working over IPv6.

We don't want the developper's to use the existence of these
tools as a excuse for not porting their apps.

   Erik

---

From: Peter Tattam <[email-masked]>
Date: Mon, 12 Jul 1999 10:21:41 +1000 (EST)

> tools as a excuse for not porting their apps.

Of course,  I agree wholeheartedly.

>    Erik

Peter

--
Peter R. Tattam                            [email-masked]
Managing Director,    Trumpet Software International Pty Ltd
Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210

---

From: Jim Bound <[email-masked]>
Date: Sun, 11 Jul 1999 22:26:39 -0400

>Those are the ones I'm particularly concerned about.

Me too.  But now that we have the v6forum we can select the top ISVs
that do a large amount of business horizontally across market segments
like the Database Vendors (Oracle, INformix, etc), ECAD/MCAD vendors
like MSC, Financial Vendors like MCSA etc.  This the forum should put on
their radar.  Then us product engineers need to be prepared to present
and discuss with ISV technical leaders and managers how to port the apps
and all the gotchas.  Or do a good job of training our field folks and
techno marketing groups.

> or takes too long, use a bump-in-foo approach to try to get the application

I agree but I highly doubt that Ford Motor Companies corporate
distriubted database is going to run over IPv6 with bump-in-foo
strategy.  Clearly some apps would be fine that don't keep any state
machines or to much cache depending on address tuples etc.. 

>tools as a excuse for not porting their apps.

Yep.

Worse yet the software market to think they don't have to port to IPv6.

/jim

---

From: Jim Bound <[email-masked]>
Date: Mon, 12 Jul 1999 10:09:20 -0400

>hmmm.  if one of the tools available to a developer is a 
>bump-in-the-foo library that can be linked in with the product,
>using this library might be a sensible means of porting the app.
>it depends on how well the app works under such conditions.

Why would this be useful to the developer?  If the implementation
supports the needed API syntax/semantics why head down that path as the
library most likely would not be the optimal means for performance, and
would not be able to take advantage of any new IPv6 features but only
apply IPv4 features to IPv6 so the full benefit of RFC 2553 could not be
used?  

>it's probably the case that there are a number of apps out there
>that are very difficult to maintain even with just IPv4, and for 
>which the maintainer will be reluctant to port the app to IPv6 if
>it requires significant changes to the code.

I have worked with several types here are some examples:  

#1 a standard app like ftp where it is just a manner of porting the 
AF_INET thingees to AF_INET6 thingees and doing the changes for the
resolver logic.   At the end you need to support v4 and v6 with same
inline code.  This is not hard and quite trivial.  The more non-trivial
part was porting to the new ftp mechanisms for prt and pasv cmds.

#2 an ISV app that hides the underlying socket/streams API
implementation and then you have to alter the underlying mechanisms as
above.  Still trivial to change the code, but more work to find out
where to change the code.

#3 dameons that must support incoming requests for service.  A bit more
tricky than #1 but the code is essentially the same.  The hard part is
doing it in a way that has optimal performance to support a dual stack.

#4 net utilities and daemons that process packets in user space.
Basically #1 again.  Again doing the engineering for optimal performance
and ease of use is more the issue.

Most of these are now just using the v4 features but given time they can
expand their capabilities to use the new features.

The advanced API rfc 2292 is even more powerful and doing a BIS for this
would be very complex and I would be surprised if anyone would take this
on.

Changing the actual lines of code is not hard its the logic choices one
uses to support a dual stack for transition. 

Porting the dns resolver to do IPv6 is work but that is a one time
investment or code integration drop from bind.

Check out:

www.ipv6.zk3-x.dec.com

click on Digital UNIX Users Guide (this should say Compaq Tru64 UNIX
Users Guide ...need to fix that)  then scroll down to porting
applications.  There are precepts and examples using RFC 2553.

/jim

---

From: Keith Moore <[email-masked]>
Date: Mon, 12 Jul 1999 01:53:40 -0400

Keith