Hi Mikhail,
> one of the really early design choices was to not expose TPDU
outside
> of
> oFono core. We do not give TPDUs to history nor do we hand them out
> over
> D-Bus. That is a fundamental design decision and even after over 2
> years
> that is still the right one.
I totally agree. But it means that you have code in oFono to reliably store an ordered
collection of stuff in a filesystem. I wouldn't like MeeGo developers to maintain very
similar code in a different component, just for API adaptation reasons.
we are storing fragments reliable with a specific efficient way of doing
so. There is nothing generic about it.
> > > Not everyone has the same requirements here, you can
have systems
> with
> > > a
> > > well defined store that do not need to cross the system/session bus
> > > boundary for instance.
> >
> > They could use the pull-style API as well, having a push method with
> a 100% success rate requirement is not necessary for this.
>
> Can someone please sit down and start counting the number of D-Bus
> messages and wakeup that are caused by exposing the message objects
> instead of using an agent.
D-Bus messages at initialization of a storage-capable client:
1. client connects to the oFono signal NewMessage.
So that are two D-Bus messages via AddMatch already.
2a. client calls ListMessages.
2b. oFono returns spooled messages.
These are already 4 D-Bus messages.
If there are any messages, two more are needed:
3a. client calls ExpungeMessages.
3b. oFono returns.
And another 2 for each message.
When a new message is received:
1. oFono emits a NewMessage signal.
2a. client calls ExpungeMessages.
2b. oFono returns.
These are another 3 per message.
And this does not include any status updates in case of submission
failed or delivery failed etc.
Now if we implement a history plugin to serve this API, there will be
all of the above plus the history plugin registration and event storage roundtrips.
> And without using an agent you have no access control of who acks
> messages.
You do, it's controlled by the security framework in D-Bus.
Without checking security tokens, you cannot trust the agent, either.
So your proposal is to make the messages available to everybody and then
put a security framework around it to not let everybody see and access
them. Instead of just controlling initial access to who gets the
messages by controlling access to the agent.
I go for the latter idea and controlling a single access point instead
of having to deal with multiple. Just good security principle.
> And additionally oFono does not store the read/unread states
> either.
It doesn't have to in my proposal.
> oFono does not implement a message store.
... while implementing a large part of the functionality needed for a simple intermediate
message spool.
Let me repeat. oFono does NOT implement a message store. We are storing
intermediate fragments if needed. That is different.
> > > > In all, we need three things from the oFono SMS
API:
> > > > * a property listing the spooled messages;
> > > > * a method to expunge some of the messages;
> > > > * a signal notifying of a new message in the spool.
> > > >
> > > Who
> > > guarantees acking of messages?
> >
> > Control plane acking is guaranteed by oFono core itself, as we seem
> to have established.
> > A client then clears the spool, if the system is not dysfunctional.
>
> I come to think that you are mixing up full SMS and TPDUs heavily here.
> Please get straight what you want. As I explained above, the TPDUs are
> oFono core business and not visible anywhere else. oFono only hands out
> fully re-assembled messages.
That's what I mean too.
So if that is clear, why do we bother with the ACK thing again?
> > > How many messages to spool?
> >
> > The filesystem is the only real limit. In a properly working system,
> you won't have to spool too many messages.
>
> Where, when, how.
The spool is cleared at a time when a client is running, for example when the user
session starts up.
The storage agent's lifetime does not have to be tied to the lifetime of oFono, as
one benefit.
I still don't get why messages need to be explicitly represented and
acked. The agent just works fine and no race conditions. Spooled
messages can just replayed once the agent registers.
> As I said above, normally this should go like this:
>
> oFono -> history plugin -> message store
> oFono -> history plugin -> call history store
>
> If the history plugin needs to spool, then that is fine. oFono is not
> spooling for history plugin since there can be an unlimited number of
> history plugin for various use cases.
If you collapse "history plugin" into oFono under a more handy pull-style API,
there can just as well be unlimited number of client usages for various use cases.
Moreover, some of the actually confirmed use cases, in MeeGo no less, can be implemented
in a simpler, less wasteful way.
There is no waste inside oFono right now and there is not waste via the
history plugin. Right now I don't really know how much more clearer I
can explain this.
> > > When to throw away messages?
> >
> > When the client tells you to.
>
> Which client? What happens if you have more then one client attempting
> to access the messages
This is not a crime and may actually be useful?
And other clients can do that as easily and way more reliable and with
more status information (like read/unread) via the message store. And
that is what you really wanna do anyway.
> or even acknowledge them.
This means either that the system is misconfigured, or the access control is too
permissive.
The basic security principle is to expose as less as possible. Think
about that for a bit.
> If you wanna go via Telepathy, then you most likely need a
Telepathy
> specific history plugin. My example gave you a basic skeleton for it
> and
> you just need to add the on-disk spooling to it.
That's what we will most likely do, but it's an unnecessary stage.
I am getting a bit tired of explaining this over and over again. It is
not an unnecessary step. oFono is not a message store and it does not
store full messages for you. oFono works on fragments and fragments
alone.
Regards
Marcel