[Shr-Devel] [Fwd: Re: Ophonekitd step to dbus / libframeworkd-phonegui dbusification]
ptitjes at free.fr
Wed Jun 3 20:51:45 CEST 2009
First, looking at the proposal of David, it seems to me that he models
the protocol session-based.
This is how I understand the things you can read as:
"Receive a criteria to filter the messages",
"Receive a number (or a list of numbers) to which write a message"
It seems to me he views the protocol as (way 1) objects created on
demand for a caller that maintains a state and can be modified in time
by the caller until the screen completes.
Where it seems to me that you view the protocol as (way 2) singletons
providing methods that can be called and point.
I would be more inclined for the primer (way 1), if this is really what
David is trying to express, as this seems to better follow the DBus way
We could argue a lot on this. Frameworkd chose way 2, where pyNeo
choosed way 1. And mickey knows what I think of their choice. And it
seems to me that FSO people may not do the same if they were to do it
now (with the experience of the API they have now).
Julien Cassignol wrote:
> Let us agree on the following "use" paradigms we want to define for functions:
> Display : which will allow the developer to display data according to
> the functional context, filtered or unfiltered, e.g. DisplayMessages,
> DisplayContacts, DisplayDialer
> EditXXX : which will precise the level used to view something, and
> allow to edit it, e.g. EditContact, EditMessage. This includes high
> level management such as "adding", "removing" (e.g. :
> EditContact(actionType= Add)...)
> These two types of actions cover a great lot of functionnalities we might need.
> Then we are left with the handling of events, I think, such as
> incoming call. Do we want to define stuff to display incoming calls
> window through dbus? Do we have a use case for such a thing, or should
> the library/ophonekitd use it as it comes? In any case, we need
> prototypes for such a thing for ophonekitd inclusion, so we might as
> well do dbus stuff too...
> So I'd say:
> HandleXXX: Handle a non user initiated event, according to type.
> HandleCall(incoming, outgoing...). HandleMessage(Incoming, sending...)
> Do these "functional" paradigms & vocabulary sound stupid to any of you?
It depends for me. If we choose way 2, then I would like to know if
DisplayXXX can be used to select stuff or not. If not, then some
SelectXXX "use paradigm" must obviously be added.
As for EditXXX, I don't see the point of actionType thingie. If this is
to show how the final technical implementation will look like and enable
CRUD (create/delete/update), then I would prefer we throw that for now.
And then simply express our functionnal needs in terms of AddXXX,
EditXXX and RemoveXXX, as it seems to me the final prototypes might be
very different one to another. If we keep that grouping in EditXXX, it
might be that we forgot some features, because creating, deleting and
updating data are really different things.
Finally, as for the active calls UI, the way the current thing is
working is IMHO sufficient and this can be left aside for now. But I'm
not against some possibility to override that behavior from some
However, IMHO if we need one thing is to define stuff to NOT display
screen for the incoming calls. Propose any protocol you want, but it
really is mandatory for me.
All the best, Didier.
More information about the Shr-devel