Hi Mikhail, On 02/04/2011 12:07 PM, [email protected] wrote: > Hi, > >> -----Original Message----- >> From: ext Denis Kenzior [mailto:[email protected]] >> Sent: Friday, February 04, 2011 7:06 PM >> To: [email protected] >> Cc: Zabaluev Mikhail (Nokia-MS/Helsinki) >> Subject: Re: [RFC 2/2] doc: Add description for history agent interface >> >>> 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 efficiently. > The only thing missing is a thin API to provide a view on complete messages. >
I think you really need to go into the code and understand what is going on there. You have a misconception of how it works. Trust me, the tpdu fragment store does not translate to any sort of D-Bus API. And once you see the code, I'm sure you will be convinced not to even bother ;) Moreover, you have to realize that there are non-text messages in that tpdu store that go via an entirely different path and unless there's a relevant plugin handling these, they will not go through history. In the text message case we already provide the history plugin with _everything_ that it needs. If you want to implement a particular API, then history is the right avenue to do so. There is no inherent benefit of having oFono core do so and we do not want to introduce the concept of a message store into oFono anyway. > So the ratio is 2/3 for the only event flow that is relevant for performance, > more likely. > But I agree, it's a bit more efficient for simple plugins, provided that they > never fall off the bus. Lets put it this way, your proposal is 1.5x slower in the absolute best case; worse if multiple clients subscribe to the signal, purposefully or otherwise. Falling off the bus has nothing to do with this performance. You can make your history plugin detect the 'falling off the bus' events and handle them appropriately (e.g. spool messages internally until the consumer comes back.) That is how every single 'Agent' in oFono / ConnMan / BlueZ works today anyway. Regards, -Denis _______________________________________________ ofono mailing list [email protected] http://lists.ofono.org/listinfo/ofono
