Le jeudi 27 novembre 2008, Eva Brucherseifer a écrit :
> Hello Matt,
>
> as discussed on IRC, we had a student investigating how to use kopete
> protocol plugins within the Telepathy infrastructure.
> Here is the promised list of issues Roman came up with. I hope it is useful
> for you.


Hi, i'll do some comments:
I think this email is better suited for kopete-devel, so i'll cross-post.
The original email and his attachement can be found here:
http://mail.kde.org/pipermail/decibel/2008-November/000167.html

http://mail.kde.org/pipermail/decibel/attachments/20081127/317585ad/attachment-0001.pdf


> 1. GUI-Calls at the libkopete-protocol-implementations

Well, we discussed that a lot.  The idea was to have a strong separation 
between the ui ans the logic.  In a ideal world, neither libkopete, neither 
plugins/protocols would do any ui call.
In a real world this is just not possible because there is many protocol or 
plugin specific ui that cannot be abstracted.

And even in libkopete, it make few sens to remove _all_ ui call just for the 
so called purity of the design. 

I think that the level of separation we have now in libkopete regarding the 
ui/logic separation is good enough.

(even is there is still some few area that could be abstracted for a better 
unification).


> 2. Parameters to connect to an account

I don't see anything wrong with the current design.

> 3. Error Handling
> In some cornercases a proper error handling is not possible:
> – if wrong account data is provided (password, user name, server) there is
> no feedpack why the process has failed.

IIRC protocols change the message of the connection dialog.

> – if a message can not be send successfully there is no feedback that an
> error occured 

You receive an error message in the chat window.

> For both cases no oiption for user notification was found in 
> the patched libkopete APIs. If there are Signals in Kopete that will be
> send as described in section 1 a better error handling is possible

There is actually 3 ways to do that.
1) an internal message in the chat window
2) a message box
3) a passive message that show a red flag on the contactlist.

choose the one that fits better the context

> 4. Text messaages to rooms

On this point I completely agree.
The chat rooms miss api and so.


> 5. Tests of different communication protocols

I don't understand this issue.

Attachment: signature.asc
Description: This is a digitally signed message part.

_______________________________________________
Decibel mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/decibel

Reply via email to