[Bug 31195] Implement models

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=31195

--- Comment #4 from Paolo Capriotti <paolo.capriotti at collabora.co.uk> 2010-11-01 03:45:45 PDT ---
(In reply to comment #3)
> I mostly agree with what was written (with the obvious reserve of what I wrote
> in my very first mail), however there are some points which are not really
> clear to me.

You mean the issue with reference counting? Maybe I'm missing something, but I
don't see the problem there. At the moment, reference counted objects are
exposed through qml-friendy wrappers, which keep the object alive internally.
Unless you store the object on the QML-side so that it outlives its container,
you shouldn't be concerned with the reference count at all.
Of course, it is always possible to delete the object in C++ code, and later
access it in QML (I believe you would get 'undefined' in this case), but that
is nothing specific to telepathy, and has simply to do with how object handles
are implemented in QML.

> For example, I don't see the need of exposing text message features.
> Considering use cases of our two main client platforms (KDE and Maemo/Meego),
> it makes no sense for an application to start a text chat - the main channel
> handler would take care of that. If there are plans for writing the CH for Text
> Channels for Meego in QML, the component could be moved there - but as for
> myself, I don't see the need of exposing this component through QML.

I don't know about Meego, but I believe there is interest in experimenting with
a QML chat handler for KDE. In any case, these models are not just for QML: I
think the kde chat handler could possibly benefit from them.

> Instead, I find it quite critical to expose Tubes and File Transfers - which
> are exactly the reason why a 3rd party app could be tempted to use Telepathy -
> and for your pleasure, also the most tricky bits to implement :)
> 
> So basically I'd like to start a discussion about "what do we want to expose?",
> because (apart from the most obvious ContactList and Account) this seems to me
> the most critical part. And, if you agree with what I said, I guess we also
> need to discuss how.

Yes, I agree that tubes and file transfers are interesting and could be wrapped
in a high-level API geared towards QML.
At the moment I'm mostly focusing on models, and I'd like to polish them and
have them merged, before moving on to more challenging stuff, but any
suggestion on how those interfaces should look like is of course welcome.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.