From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============6622044194703077631==" MIME-Version: 1.0 From: Marcel Holtmann Subject: RE: [RFC 2/2] doc: Add description for history agent interface Date: Fri, 04 Feb 2011 10:13:07 -0800 Message-ID: <1296843187.1520.391.camel@aeonflux> In-Reply-To: List-Id: To: ofono@ofono.org --===============6622044194703077631== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi Mikhail, > > > 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. > > = > > No we do not. We have code to reliably store tpdus, fragments not > > re-assembled messages. It is not ordered or anything else you make it > > out to be. Why don't you actually read the sms_assembly code and tell > > me if it is usable for anything else. The code for storing assembled > > messages would be _completely_ different. > = > Why, you already cache fragments by their respective message refs efficie= ntly. > The only thing missing is a thin API to provide a view on complete messag= es. we are not storing the complete message. We give it to the history API. > > > D-Bus messages at initialization of a storage-capable client: > > > > > > 1. client connects to the oFono signal NewMessage. > > > 2a. client calls ListMessages. > > > 2b. oFono returns spooled messages. > > > > > > If there are any messages, two more are needed: > > > > > > 3a. client calls ExpungeMessages. > > > 3b. oFono returns. > > > > > > When a new message is received: > > > > > > 1. oFono emits a NewMessage signal. > > > 2a. client calls ExpungeMessages. > > > 2b. oFono returns. > > > > > > 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. > > = > > You are proving Marcel's point here, the Agent has about 1/2 as many > > round trips as your proposal. > > = > > 1. client calls RegisterAgent() > = > An interesting question here: should oFono core monitor NameOwnerChanged = for the agent's service name, just in case it disappears from the bus? What= 's the failure mode for this case? You do have read my RFC patch, right? It does exactly this. > > 2. For each new message the agent's HandleMessage() method is called > = > 2a. agent returns. > = > So the ratio is 2/3 for the only event flow that is relevant for performa= nce, more likely. > But I agree, it's a bit more efficient for simple plugins, provided that = they never fall off the bus. What has falling off the bus to do with this? Regards Marcel --===============6622044194703077631==--