Hi Marcel, On 10/07/2011 05:03 PM, Marcel Holtmann wrote: >>> Here some questions about the Session API proposal. I admit don't get >>> the whole picture, and I'm missing all of your use cases. >> >> I feared I failed to explain it good enough. Hopefully I can clarify >> some things. >> >>> However, I >>> would not want to add any more complexity into ConnMan than what is >>> necessary. >> >> I absolutely agree. So my proposal tries to only to add stuff which is >> really needed. > > I think it might be good even split updates for the documentation into > one or two per patch. That makes it easier to comment on these without > loosing the context.
Good point. I'll prepare a spited version of this patch. >>> On Thu, 2011-10-06 at 18:46 +0200, Daniel Wagner wrote: >>>> + string SessionId [readwrite] >>>> + >>>> + Applications which want to get a preconfigured >>>> + session can pass in a ID with Manager.CreateSession(). >>> >>> Preconfigured session? If applications don't know anything about >>> sessions, would it be better to just go with free ride and let someone >>> else do the connecting and disconnecting? >> >> There are a few reasons behind why ConnMan should also support >> preconfiguration and provisioning and not only rely on the applications. >> >> The following reasoning is based on the IVI use cases. We have an >> architecture in mind for supporting them. Let me try to explain it. >> >> We have a central database for (all sorts of) configurations. This >> configuration might change at anytime. Furthermore, we want to enforce >> those configuration on applications. The idea behind this is that if we >> would have 3rd party application we don't have really control over them >> we still can make sure they don't go too wild. >> >> The way the configuration is set to the session is not the killer >> argument for having ConnMan to do it. The main argument for is how you >> want to enforce these settings. There are two ways to do it. >> >> First one is we would introduce a proxy between ConnMan and any >> application which intercepts the Session API calls. We rather don't like >> to do this, because you introduce a lot of unnecessary runtime >> dependencies and also double the D-Bus communication. >> >> Second one is ConnMan does this itself. This feature should be >> implemented through a plugin. >> >> I have discussed this with Marcel offline and he also suggested to move >> this enforcement part into ConnMan. >> >> So coming to your question, the SessionId is used to get the correct >> configuration. BTW, for our use cases, the most interesting >> configuration part is the roaming one. So is an application allowed to >> use a roaming service or not. The application is still able to call >> Connect()/Disconnect() but it should care about the rest. So the whole >> configuration part is done under the hood. > > I personally think we should just use the D-Bus well known name for this > part. Making the application give an extra magic cookie seems useless. For those proxy application (e.g. as the mentioned communication middle ware) it is very helpful. Otherwise the whole preconfiguration/provisioning stuff doesn't work and the proxy application has to talk to the configuration database itself. cheers, daniel _______________________________________________ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
