[Shr-Devel] [Fwd: Re: Ophonekitd step to dbus / libframeworkd-phonegui dbusification]

[Didier "Ptitjes"]

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",
or
"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 
of things.

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:
> Addenda:
> 
> 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...)
> Etc.
> 
> 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 
external component.

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.