Re: [mif] Adoption of API document as the MIF WG document

[<[e-mail]>]

> -----Message d'origine-----
> De : Simon Perreault [mailto:[e-mail]]
> Envoyé : mardi 20 décembre 2011 15:11
> À : SEITE Pierrick RD-RESA-REN
> Cc : [e-mail]; [e-mail]
> Objet : Re: [mif] Adoption of API document as the MIF WG document
> 
> On 2011-12-20 08:48, [e-mail] wrote:
> > I'm just trying to understand the scope of the MIF API and meaning of
> high/low
> > level API.
> >
> > So, thinking about high-level requirements: IMU, the MIF API should
> address
> > issues from the problem statement : DNS selection, source address
> selection and
> > routing. Right? Considering these problems, the MIF API should be
> able to provide
> > command/services to high level API (e.g. OMA-DM API), or even
> applications (if we
> > imagine application with MIF management capabilities...). Typically,
> I'm thinking
> > to the following requirements for the MIF API:
> >
> > DNS selection:
> >
> > -bound some DNS servers to an interface and suffixes.
> >
> > source address selection:
> >
> > -return the type of IP address (e.g. local, remote, mobile IP
> anchored
> >
> > -provide a valid IP address with a given type on a given interface
> >
> > routing / first-hop selection:
> >
> > -the API should allow to differentiate the traffic (i.e. provide
> capability to
> > configure traffic selector)
> >
> > -associate a routing table per type of traffic
> 
> I think this is all low-level stuff.
> 

Agreed.

> Ideally, an application shouldn't have to deal with this stuff. It
> should be
> handled as automatically as possible by the stack. The high-level API
> should be
> as close to the "use case" as possible. For example, (I'm just
> inventing stuff
> now, not sure it makes sense), with an appropriate high-level API an
> application
> could just pass a flag saying "don't use a cellular interface".
> 
> The idea is that you don't want all apps to have to reimplement similar
> logic
> each time. The similar stuff can be abstracted away and put in the
> platform's stack.
> 


I couldn't agree more :-) Your high-level API is what I use to name "a connection manager"... Whatever the terminology, I think this is the right way to go if want harmonization in the field. At least, it should be the default API model; however, some application developers may want to keep control of the connectivity and may want to have access to low-level API (I'm not sure it is desirable...). Let's see what the WG think.... 

Pierrick

> Simon
> --
> DTN made easy, lean, and smart --> http://postellation.viagenie.ca
> NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
> STUN/TURN server               --> http://numb.viagenie.ca