On rewriting the text chat stack

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

On rewriting the text chat stack

Julien PUYDT
Hi,

I would like to help redesign the ekiga chat core. Of course, that means
one should have a look at how text chat happens within various protocols
beforehand.


With IRC (https://tools.ietf.org/html/rfc1459):

- you connect to a server, where you have a nickname, and the server
will send you messages (welcome, notices...) -- notice you can't
connect as the same nickname from different places simultaneously ;

- you can then join (and even create) a room [called a channel] where
you can see the list of members, each with some notion of presence
(away state), and a notion of role (voice, op). It can have a title
and you can get kicked or banned from a room, or invited to one ;

- you send messages to a single user, to a list of users or to a room
and as far as I know the server doesn't send you back your own
messages (so you have to note them yourself!) ;

- I don't think a one-to-one conversation is more than messages with
the same person (nickname, in fact) -- so there's no way to have
various conversations with the same person, and no way to turn a
one-to-one into a many-many one ; and also in a one-to-many I'm not
sure recipients know of each other, so they can't just reply to all.


With MSN (I haven't found decent&recent documentation):

- you connect to a server with an account, and you can connect to it
from several places ; I think you can have a nickname on the server ;
it's also where the contact list is ;

- you can then send one-to-one messages, or join/create rooms
(multiparty) ; I don't think you can have a room-specific nickname and
I don't know if the server sends you your own messages ;

- I don't think a one-to-one conversation is more than messages with
the same person -- so again, no way to have various conversations with
the same person ;

- I don't know if rooms have title, if there is special presence and
   roles.


With Jabber (http://xmpp.org/):

- you connect to a server, and you can connect to it from several places
; it's
also where the contact list (named roster) is ; the presence exchange is at
the server level ;

- you can send messages one-to-one or join/create a room. One-to-many
exists, but isn't natural (even with XEP-0033) ;

- the interesting thing about one-to-one is that you can either send
the messages in a one-off fashion or with a threading information (see
5.1 in RFC 6121). In this case it's possible to have different
conversations with the same contact, and it's possible to turn a
private conversation into a group conversation, which others can join
(see section 7.9 of XEP-0045 - notice how the client is supposed to
send the history to the room) ;

- a chat room has a title, a list of occupants with their own presence
(you might in fact not even know the "real identity" of the occupants:
the nickname is per-room!) with roles ; it also has a history which
new joiners will receive.


With SIP: here I shall wait for a reply, as I'm definitely not qualified
to discuss it at length.

I'm not sure I'm 100% right on all of the above: feedback is welcome!


Cheers,

Snark
_______________________________________________
ekiga-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
a
Reply | Threaded
Open this post in threaded view
|

Re: ekiga chat - Suggestion -> LINE

a
Don't forget Naver's LINE: http://line.me/en/
This program doesn't even have a linux version yet!

On Fri, 9 Oct 2015 18:18:23 +0200
Julien Puydt <[hidden email]> wrote:

> Hi,
>
> I would like to help redesign the ekiga chat core. Of course, that
> means one should have a look at how text chat happens within various
> protocols beforehand.
>
>
> With IRC (https://tools.ietf.org/html/rfc1459):
>
> - you connect to a server, where you have a nickname, and the server
> will send you messages (welcome, notices...) -- notice you can't
> connect as the same nickname from different places simultaneously ;
>
> - you can then join (and even create) a room [called a channel] where
> you can see the list of members, each with some notion of presence
> (away state), and a notion of role (voice, op). It can have a title
> and you can get kicked or banned from a room, or invited to one ;
>
> - you send messages to a single user, to a list of users or to a room
> and as far as I know the server doesn't send you back your own
> messages (so you have to note them yourself!) ;
>
> - I don't think a one-to-one conversation is more than messages with
> the same person (nickname, in fact) -- so there's no way to have
> various conversations with the same person, and no way to turn a
> one-to-one into a many-many one ; and also in a one-to-many I'm not
> sure recipients know of each other, so they can't just reply to all.
>
>
> With MSN (I haven't found decent&recent documentation):
>
> - you connect to a server with an account, and you can connect to it
> from several places ; I think you can have a nickname on the server ;
> it's also where the contact list is ;
>
> - you can then send one-to-one messages, or join/create rooms
> (multiparty) ; I don't think you can have a room-specific nickname and
> I don't know if the server sends you your own messages ;
>
> - I don't think a one-to-one conversation is more than messages with
> the same person -- so again, no way to have various conversations with
> the same person ;
>
> - I don't know if rooms have title, if there is special presence and
>    roles.
>
>
> With Jabber (http://xmpp.org/):
>
> - you connect to a server, and you can connect to it from several
> places ; it's
> also where the contact list (named roster) is ; the presence exchange
> is at the server level ;
>
> - you can send messages one-to-one or join/create a room. One-to-many
> exists, but isn't natural (even with XEP-0033) ;
>
> - the interesting thing about one-to-one is that you can either send
> the messages in a one-off fashion or with a threading information (see
> 5.1 in RFC 6121). In this case it's possible to have different
> conversations with the same contact, and it's possible to turn a
> private conversation into a group conversation, which others can join
> (see section 7.9 of XEP-0045 - notice how the client is supposed to
> send the history to the room) ;
>
> - a chat room has a title, a list of occupants with their own presence
> (you might in fact not even know the "real identity" of the occupants:
> the nickname is per-room!) with roles ; it also has a history which
> new joiners will receive.
>
>
> With SIP: here I shall wait for a reply, as I'm definitely not
> qualified to discuss it at length.
>
> I'm not sure I'm 100% right on all of the above: feedback is welcome!
>
>
> Cheers,
>
> Snark
> _______________________________________________
> ekiga-devel-list mailing list
> [hidden email]
> https://mail.gnome.org/mailman/listinfo/ekiga-devel-list


--
[hidden email] <[hidden email]>
_______________________________________________
ekiga-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: ekiga chat - Suggestion -> LINE

Julien PUYDT
Le 10/10/2015 05:35, a a écrit :
> Don't forget Naver's LINE: http://line.me/en/
> This program doesn't even have a linux version yet!

Does it have an open protocol which might make it relevant in this
discussion ?

Snark
_______________________________________________
ekiga-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: On rewriting the text chat stack

Damien Sandras
In reply to this post by Julien PUYDT
Hi Julien,

Thanks for getting back into this.

In SIP, I see two basic ways of having Chat sessions :
- Using the SIP MESSAGE request. It works like an SMS. You do not have a notion of "conversation", you just send a simple text message somewhere. That is what Ekiga supports until now.
- Using the MSRP protocol. It works like a "Text Call". You have a notion of "conversation" between two peers and notifications indicating that the remote is typing.

However, MSRP brings more features than simple text chat :
- File Transfer over MSRP
- Screen Sharing over MSRP

You also have extensions :
- Multi-participants chat rooms
- Conference information through the "conference-info" Event package

I think we should keep this in mind, but limit ourselves to 1-to-1 conversations for now.

Le vendredi 09 octobre 2015 à 18:18 +0200, Julien Puydt a écrit :
Hi,

I would like to help redesign the ekiga chat core. Of course, that means 
one should have a look at how text chat happens within various protocols 
beforehand.


With IRC (https://tools.ietf.org/html/rfc1459):

- you connect to a server, where you have a nickname, and the server
will send you messages (welcome, notices...) -- notice you can't
connect as the same nickname from different places simultaneously ;

- you can then join (and even create) a room [called a channel] where
you can see the list of members, each with some notion of presence
(away state), and a notion of role (voice, op). It can have a title
and you can get kicked or banned from a room, or invited to one ;

- you send messages to a single user, to a list of users or to a room
and as far as I know the server doesn't send you back your own
messages (so you have to note them yourself!) ;

- I don't think a one-to-one conversation is more than messages with
the same person (nickname, in fact) -- so there's no way to have
various conversations with the same person, and no way to turn a
one-to-one into a many-many one ; and also in a one-to-many I'm not
sure recipients know of each other, so they can't just reply to all.


With MSN (I haven't found decent&recent documentation):

- you connect to a server with an account, and you can connect to it
from several places ; I think you can have a nickname on the server ;
it's also where the contact list is ;

- you can then send one-to-one messages, or join/create rooms
(multiparty) ; I don't think you can have a room-specific nickname and
I don't know if the server sends you your own messages ;

- I don't think a one-to-one conversation is more than messages with
the same person -- so again, no way to have various conversations with
the same person ;

- I don't know if rooms have title, if there is special presence and
   roles.


With Jabber (http://xmpp.org/):

- you connect to a server, and you can connect to it from several places 
; it's
also where the contact list (named roster) is ; the presence exchange is at
the server level ;

- you can send messages one-to-one or join/create a room. One-to-many
exists, but isn't natural (even with XEP-0033) ;

- the interesting thing about one-to-one is that you can either send
the messages in a one-off fashion or with a threading information (see
5.1 in RFC 6121). In this case it's possible to have different
conversations with the same contact, and it's possible to turn a
private conversation into a group conversation, which others can join
(see section 7.9 of XEP-0045 - notice how the client is supposed to
send the history to the room) ;

- a chat room has a title, a list of occupants with their own presence
(you might in fact not even know the "real identity" of the occupants:
the nickname is per-room!) with roles ; it also has a history which
new joiners will receive.


With SIP: here I shall wait for a reply, as I'm definitely not qualified 
to discuss it at length.

I'm not sure I'm 100% right on all of the above: feedback is welcome!


Cheers,

Snark
_______________________________________________
ekiga-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
--
Damien SANDRAS

Ekiga Project
http://www.ekiga.org

_______________________________________________
ekiga-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: On rewriting the text chat stack

Eugen Dedu-2
Hi,

Thanks, Julien, if you could implement the chat, right now it is the
only important regression I think (compared to v4).

First of all, I think it is essential to implement ONLY ONE METHOD,
completely and bug-free, so that it becomes usable by all users.  It
should especially be avoided to implement several protocols and none of
them working.  Better to have one protocol working in 2 months than all
of them working only in several years by now.  In my opinion, 200-400
lines dealing with chat backend can be later updated to another
protocol, if really needed.

Second point, currently we do not have enough man-power to implement all
the open chat protocols you mentioned.  I wonder if we will ever have,
knowing that there are other things in Ekiga which are more important in
my opinion (secure videoconferencing, Ekiga.net, multi-user conference,
echo cancelling etc. etc.)  Again, let's work on only one of them so
that a person can send a message to another one (one to one, not one to
many), in particular to the one he is doing videoconference with.

Third, as far as I understand, SIP MESSAGE, or better MSRP if possible
in a reasonable time, is the most appropriate chat protocol in our case.
  Ekiga's main mission is videoconferencing, not supporting all chat
protocols, for which there are other programs, much more advanced than
Ekiga.

Finally, would you mind to contact us when you will work on GUI for
chat?  For example, should text chat be in the same window as the video,
or on its own?  I do not yet have an idea...

As a side note, see also
https://bugzilla.gnome.org/show_bug.cgi?id=651837:  "The correct way to
receive Instant Messages is via the new OpalIMContext class. This will
allow for future non-SIP IM to be used. For example, there are a lot of
Jabber (XMPP) classes already in PTLib, one day in the not too distant
future, I hope, we will bolt that into the OPAL system and there will be
OpalPresentity and OpalIMContext derived concrete classes so the user
application will barely change at all."

Happy hacking,
Eugen


On 10/10/15 13:58, Damien Sandras wrote:

> Hi Julien,
> Thanks for getting back into this.
> In SIP, I see two basic ways of having Chat sessions :
> - Using the SIP MESSAGE request. It works like an SMS. You do not have
> a notion of "conversation", you just send a simple text message
> somewhere. That is what Ekiga supports until now.
> - Using the MSRP protocol. It works like a "Text Call". You have a
> notion of "conversation" between two peers and notifications indicating
> that the remote is typing.
> However, MSRP brings more features than simple text chat :
> - File Transfer over MSRP
> - Screen Sharing over MSRP
> You also have extensions :
> - Multi-participants chat rooms
> - Conference information through the "conference-info" Event package
> I think we should keep this in mind, but limit ourselves to 1-to-1
> conversations for now.
> Le vendredi 09 octobre 2015 à 18:18 +0200, Julien Puydt a écrit :
>> Hi,
>>
>> I would like to help redesign the ekiga chat core. Of course, that
>> means
>> one should have a look at how text chat happens within various
>> protocols
>> beforehand.
>>
>>
>> With IRC (https://tools.ietf.org/html/rfc1459):
>>
>> - you connect to a server, where you have a nickname, and the server
>> will send you messages (welcome, notices...) -- notice you can't
>> connect as the same nickname from different places simultaneously ;
>>
>> - you can then join (and even create) a room [called a channel] where
>> you can see the list of members, each with some notion of presence
>> (away state), and a notion of role (voice, op). It can have a title
>> and you can get kicked or banned from a room, or invited to one ;
>>
>> - you send messages to a single user, to a list of users or to a room
>> and as far as I know the server doesn't send you back your own
>> messages (so you have to note them yourself!) ;
>>
>> - I don't think a one-to-one conversation is more than messages with
>> the same person (nickname, in fact) -- so there's no way to have
>> various conversations with the same person, and no way to turn a
>> one-to-one into a many-many one ; and also in a one-to-many I'm not
>> sure recipients know of each other, so they can't just reply to all.
>>
>>
>> With MSN (I haven't found decent&recent documentation):
>>
>> - you connect to a server with an account, and you can connect to it
>> from several places ; I think you can have a nickname on the server ;
>> it's also where the contact list is ;
>>
>> - you can then send one-to-one messages, or join/create rooms
>> (multiparty) ; I don't think you can have a room-specific nickname
>> and
>> I don't know if the server sends you your own messages ;
>>
>> - I don't think a one-to-one conversation is more than messages with
>> the same person -- so again, no way to have various conversations
>> with
>> the same person ;
>>
>> - I don't know if rooms have title, if there is special presence and
>>     roles.
>>
>>
>> With Jabber (http://xmpp.org/):
>>
>> - you connect to a server, and you can connect to it from several
>> places
>> ; it's
>> also where the contact list (named roster) is ; the presence exchange
>> is at
>> the server level ;
>>
>> - you can send messages one-to-one or join/create a room. One-to-many
>> exists, but isn't natural (even with XEP-0033) ;
>>
>> - the interesting thing about one-to-one is that you can either send
>> the messages in a one-off fashion or with a threading information
>> (see
>> 5.1 in RFC 6121). In this case it's possible to have different
>> conversations with the same contact, and it's possible to turn a
>> private conversation into a group conversation, which others can join
>> (see section 7.9 of XEP-0045 - notice how the client is supposed to
>> send the history to the room) ;
>>
>> - a chat room has a title, a list of occupants with their own
>> presence
>> (you might in fact not even know the "real identity" of the
>> occupants:
>> the nickname is per-room!) with roles ; it also has a history which
>> new joiners will receive.
>>
>>
>> With SIP: here I shall wait for a reply, as I'm definitely not
>> qualified
>> to discuss it at length.
>>
>> I'm not sure I'm 100% right on all of the above: feedback is welcome!
>>
>>
>> Cheers,
>>
>> Snark

_______________________________________________
ekiga-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: On rewriting the text chat stack

Julien PUYDT
Hi,

Le 16/10/2015 18:36, Eugen Dedu a écrit :
> Thanks, Julien, if you could implement the chat, right now it is the
> only important regression I think (compared to v4).

In which chat was pretty bad...

> First of all, I think it is essential to implement ONLY ONE METHOD,
> completely and bug-free, so that it becomes usable by all users.  It
> should especially be avoided to implement several protocols and none of
> them working.  Better to have one protocol working in 2 months than all
> of them working only in several years by now.  In my opinion, 200-400
> lines dealing with chat backend can be later updated to another
> protocol, if really needed.

The goal isn't to implement all protocols -- it's to build things
cleanly enough so it doesn't become a headache later.

> Second point, currently we do not have enough man-power to implement all
> the open chat protocols you mentioned.  I wonder if we will ever have,
> knowing that there are other things in Ekiga which are more important in
> my opinion (secure videoconferencing, Ekiga.net, multi-user conference,
> echo cancelling etc. etc.)  Again, let's work on only one of them so
> that a person can send a message to another one (one to one, not one to
> many), in particular to the one he is doing videoconference with.

Yes, one implementation, but the framework must be sound and not get in
the way of a second.

> Third, as far as I understand, SIP MESSAGE, or better MSRP if possible
> in a reasonable time, is the most appropriate chat protocol in our case.
>   Ekiga's main mission is videoconferencing, not supporting all chat
> protocols, for which there are other programs, much more advanced than
> Ekiga.

Yes.

> Finally, would you mind to contact us when you will work on GUI for
> chat?  For example, should text chat be in the same window as the video,
> or on its own?  I do not yet have an idea...

Well, GUI isn't my strong point, but I think having the text in a window
and the fact of the other person in another is pretty inconvenient, so
there should be a way to put both side-to-side.

> As a side note, see also
> https://bugzilla.gnome.org/show_bug.cgi?id=651837:  "The correct way to
> receive Instant Messages is via the new OpalIMContext class. This will
> allow for future non-SIP IM to be used. For example, there are a lot of
> Jabber (XMPP) classes already in PTLib, one day in the not too distant
> future, I hope, we will bolt that into the OPAL system and there will be
> OpalPresentity and OpalIMContext derived concrete classes so the user
> application will barely change at all."

That's a good thing to have in mind for the one implementation, thanks
for the reminder. And it can help to see how things are organised there.
I'm also having a look at pidgin's sources.

> Happy hacking,

Well, I'm still on the thinking side of things : writing comes later.

Snark
_______________________________________________
ekiga-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: On rewriting the text chat stack

Damien Sandras
Le samedi 17 octobre 2015 à 23:20 +0200, Julien Puydt a écrit :

Finally, would you mind to contact us when you will work on GUI for chat? For example, should text chat be in the same window as the video, or on its own? I do not yet have an idea...
Well, GUI isn't my strong point, but I think having the text in a window and the fact of the other person in another is pretty inconvenient, so there should be a way to put both side-to-side.

On the other hand, I think you are not supposed to have text and video at the same time. You will probably discuss using text chat before initiating a video call, and most of the time, the video call will go full screen.

From my point of view, I would keep them in separate windows for now. It is also less work.

--
Damien SANDRAS

Ekiga Project
http://www.ekiga.org

_______________________________________________
ekiga-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: On rewriting the text chat stack

Eugen Dedu-2
In reply to this post by Julien PUYDT
On 17/10/15 23:20, Julien Puydt wrote:

> Hi,
>
> Le 16/10/2015 18:36, Eugen Dedu a écrit :
>> First of all, I think it is essential to implement ONLY ONE METHOD,
>> completely and bug-free, so that it becomes usable by all users.  It
>> should especially be avoided to implement several protocols and none of
>> them working.  Better to have one protocol working in 2 months than all
>> of them working only in several years by now.  In my opinion, 200-400
>> lines dealing with chat backend can be later updated to another
>> protocol, if really needed.
>
> The goal isn't to implement all protocols -- it's to build things
> cleanly enough so it doesn't become a headache later.
>
>> Second point, currently we do not have enough man-power to implement all
>> the open chat protocols you mentioned.  I wonder if we will ever have,
>> knowing that there are other things in Ekiga which are more important in
>> my opinion (secure videoconferencing, Ekiga.net, multi-user conference,
>> echo cancelling etc. etc.)  Again, let's work on only one of them so
>> that a person can send a message to another one (one to one, not one to
>> many), in particular to the one he is doing videoconference with.
>
> Yes, one implementation, but the framework must be sound and not get in
> the way of a second.

This is exactly the point I wanted to address.  I see that you do not
agree with me, but I think it is better for Ekiga project to implement
ONE protocol/framework as fast and simple as possible, and only when you
or someone else wants to implement another protocol, change the
code/framework so that both can coexist gracefully.

Of course, if the code/framework has almost the same complexity (e.g. 10
lines more and no additional class/variable), then it is fine to think
at a global framework right now.  But, after reading characteristics of
the protocols you cited, I see that they are too different (one to one /
one to many, create rooms or not, nickname / account, room titles or
not, presence, history etc.)

To resume, I suggest to implement something functional in a short time,
instead of having a currently-good global framework with a more complex
code and only one implementation and which takes more time.

--
Eugen
_______________________________________________
ekiga-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: On rewriting the text chat stack

Julien PUYDT
In reply to this post by Julien PUYDT
Le 17/10/2015 23:20, Julien Puydt a écrit :
> Well, I'm still on the thinking side of things : writing comes later.

I'm still thinking, but now also poking around ekiga's code to see what
changed.

I'm a bit annoyed I didn't find a heap-view widget, because I thought we
had one and wanted to make good use of it :-/

Things aren't progressing nicely, but at least things move forward!

Snark
_______________________________________________
ekiga-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: On rewriting the text chat stack

Julien Puydt-2
Hi,

Le 16/11/2015 10:58, Julien Puydt a écrit :
> Le 17/10/2015 23:20, Julien Puydt a écrit :
>> Well, I'm still on the thinking side of things : writing comes later.
>
> I'm still thinking, but now also poking around ekiga's code to see what
> changed.
>
> I'm a bit annoyed I didn't find a heap-view widget, because I thought we
> had one and wanted to make good use of it :-/

I propose to extend the base Ekiga::Presentity class with this api call:
virtual const std::list<std::string> get_emblems () const = 0;

The said emblems would appear in the GUI as little icons decorating the
presentity and be used in the following use-cases :
- in the main contact view, we could have information about how
privileged the contact is (for example those able to call us even in
do-not-disturb would have a star/heart shape in their emblems list) ;
- in a chat room's heap view, the emblems could materialize people
having voice or operator privileges ;
- in chat room's heap view again, the is-composing feature could be just
a "is-composing" emblem...

What do you think about it?

Snark
_______________________________________________
ekiga-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: On rewriting the text chat stack

Eugen Dedu-2
On 16/11/15 21:10, Julien Puydt wrote:

> Hi,
>
> Le 16/11/2015 10:58, Julien Puydt a écrit :
>> Le 17/10/2015 23:20, Julien Puydt a écrit :
>>> Well, I'm still on the thinking side of things : writing comes later.
>>
>> I'm still thinking, but now also poking around ekiga's code to see what
>> changed.
>>
>> I'm a bit annoyed I didn't find a heap-view widget, because I thought we
>> had one and wanted to make good use of it :-/
>
> I propose to extend the base Ekiga::Presentity class with this api call:
> virtual const std::list<std::string> get_emblems () const = 0;
>
> The said emblems would appear in the GUI as little icons decorating the
> presentity and be used in the following use-cases :
> - in the main contact view, we could have information about how
> privileged the contact is (for example those able to call us even in
> do-not-disturb would have a star/heart shape in their emblems list) ;
> - in a chat room's heap view, the emblems could materialize people
> having voice or operator privileges ;
> - in chat room's heap view again, the is-composing feature could be just
> a "is-composing" emblem...

Hi Julien,

Is this about the chat?  If you could work on the chat, it would be
excellent, as this is what we need now.  We could let the emblems for
later, once the chat is working.

Have a good day,
--
Eugen
_______________________________________________
ekiga-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: On rewriting the text chat stack

Julien Puydt-2
Hi,

Le mardi 17 nov. 2015 à 11:18:16 (+0100), Eugen Dedu a écrit :
> Is this about the chat?  If you could work on the chat, it would be
> excellent, as this is what we need now.  We could let the emblems for later,
> once the chat is working.

Well, I started to write some code. There needs three stages :
- an engine framework (abstract) ;
- an opal implementation (concrete) ;
- a GUI (concrete).

I know what to write for the first stage, I have started reading the
opal code in ekiga to find out what to write for the second stage, and I
have no clue yet for the third stage. I only saw there was no heap
widget... But for a first simple run, we can probably get away without
it.

It's slow, but I have my hands full...

Snark
_______________________________________________
ekiga-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: On rewriting the text chat stack

Damien Sandras
Le mardi 17 novembre 2015 à 17:13 +0100, Julien Puydt a écrit :
Hi,

Le mardi 17 nov. 2015 à 11:18:16 (+0100), Eugen Dedu a écrit :
Is this about the chat? If you could work on the chat, it would be excellent, as this is what we need now. We could let the emblems for later, once the chat is working.
Well, I started to write some code. There needs three stages : - an engine framework (abstract) ; - an opal implementation (concrete) ; - a GUI (concrete). I know what to write for the first stage, I have started reading the opal code in ekiga to find out what to write for the second stage, and I have no clue yet for the third stage. I only saw there was no heap widget... But for a first simple run, we can probably get away without it.

I think we used to have one. But at some point, I removed some unused code. I guess it was part of it.

Of course, it can be reanimated at any time. But I also think we do not need it yet.


--
Damien SANDRAS

Ekiga Project
http://www.ekiga.org

_______________________________________________
ekiga-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: <DKIM> Re: On rewriting the text chat stack

Julien Puydt-2
In reply to this post by Julien Puydt-2
Hi,

Le 17/11/2015 17:13, Julien Puydt a écrit :
> Le mardi 17 nov. 2015 à 11:18:16 (+0100), Eugen Dedu a écrit :
>> Is this about the chat?  If you could work on the chat, it would be
>> excellent, as this is what we need now.  We could let the emblems for later,
>> once the chat is working.
>
> Well, I started to write some code. There needs three stages :
> - an engine framework (abstract) ;

I have something for that, which is mostly what used to be there...

> - an opal implementation (concrete) ;

I'm working on that part now, and I have a question: what goes in the
process/ subdirectory of lib/engine/components/opal/ ?

> - a GUI (concrete).

Nothing done on that part, even though I keep it in mind.

Cheers,

Snark
_______________________________________________
ekiga-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: <DKIM> Re: On rewriting the text chat stack

Damien Sandras

> I'm working on that part now, and I have a question: what goes in the process/ subdirectory of lib/engine/components/opal/ ?-- 

Well, the engine "uses" the process. So, the real implementation must go in the process/ part of the code, and the API must lie in the classical directory.

_______________________________________________
ekiga-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list