[mif] A question about API

[Stjepan Groš <[e-mail]>]

Hi all!

We've been working on implementation of MIF on Linux/Fedora as we
announced and one thing that pops up now and then is the question of API
design. Looking at the existing proposals there were two approaches so
far (with some notes/comments):

1. Abstract description of API functionality (draft-ietf-mif-api-extension)
=> specifies functionality to be provided by MIF implementation
=> uses concepts of message passing for communication
=> doesn't touch on socket API
=> changes socket API by introducing certain messages, e.g. "Connect to
Address From Address", "Connect to Address".
=> certain messages are oriented towards power aware devices

2. socket API changes (draft-liu-mif-socket-api)
=> missing "accept" call in typical server scenario
=> proposed changes to setsockopt() and getaddrinfo() break backwards
compatibility
=> setsockopt() is a kernel function and modifying this function implies
kernel being aware of PvDs

The questions we have are:

1. Is it really necessary to change socket API?

2. Is it really necessary to make kernel PvD aware?

I think that the answer to both questions is No.  Here is why:

1. socket API and MIP API can be orthogonal, e.g. when PvD aware
application wants to use certain PvD for some connection, it should do
something like:

pvd_select(pvdID)
s = socket(...)

and thats it. Non-PvD aware applications, on the other hand, can be
placed within certain PvD (which is implementation dependent) and when
they call socket() function, selected PvD will be used.

2. Certain support from kernel is necessary, but since not everything
can be done within a kernel (DNS lookups) and performance doesn't seem
an issue, it follows that as much as possible should go into the user space.

What are you comments/thoughts about all this?

SG