Hi Daniel,
> >>>> In the current Connman version the "state" of the manager API is
> >>>> either "offline" or "online".
> >>>> If only one device is marked as connected the global state is "online".
> >>>>
> >>>> So the global online state doesn't have the same signification for the
> >>>> service state, it's a little bit confusing.
> >>>>
> >>>> The service state makes the difference between "online" and "ready"
> >>>> and detects well the Internet availability.
> >>>>
> >>>> Why don't we notifies a global state "online" when we have Internet
> >>>> and "ready" when we have an IP configuration ?
> >>>>
> >>>> He could be usefull for the applications who are waiting for Internet
> >>>> without checking the whole list of services state.
> >>>
> >>> I rather have applications use the Session API, than this global state.
> >>>
> >>> And maybe we just better remove it before 1.0 release.
> >>
> >> -1. While it certainly has its limitations, the simplicity of the
> >> Manager.State element has value and, at this point, I'd rather avoid
> >> having to rewrite most of our application when transitioning from 0.76 to
> >> 1.0.
> >
> > fair enough actually.
> >
> > So should we keep it as "online" and "offline"? So pretty simple. Or
> > should we introduce an extra state for when we have a connection, but
> > not yet confirmed that it is actually a valid Internet connection.
> >
> > And that said, the "connected" state that gets mentioned in the API
> > documentation needs to be removed. That is just some left-over from
> > earlier times and makes no sense anymore.
>
> I would say having the same values and semantics as in the Session API
> would make most sense, e.g. State = { "disconnected", "connected",
> "online" }
I am not really convinced that these state names are the best either.
We might need to think about using classification names of the type of
the current connection. Something similar to what IPv6 actually does
with link-local and global concepts.
Or we just go with "idle", "ready" and "online" to map it to what we
have inside the Service API.
Comments?
Regards
Marcel
_______________________________________________
connman mailing list
[email protected]
http://lists.connman.net/listinfo/connman
