--sent from my mobile
> From: Emil Ivov [mailto:firstname.lastname@example.org]
> Hey Tom,
> >> From: Emil Ivov [mailto:email@example.com]
> Note that chats would be complicated because we don't currently have
> conversation management within Jitsi's GUI and you would have to manage
> this in the implementation.
Please elaborate, not sure I follow and need some design-info:
The GUI does not have the concept of a conversation with a start and an
end. It just deals with individual messages. For example, it will be up to
you to decide, within the protocol, when to close a chat. There will be no
indication from the GUI about this.
File transfers are however session oriented and a first implementation and
integration would much simpler there.
Came more-and-more to the conclusion that I need to drop any tie-in to
Handling INVITE's that both contain audio-sdp *and* message-sdp is Utopia.
That's reasonable and we had the same goal when Joao was first taking a
stab at this a few years ago. Back then we decided we would simply reject
INVITEs that have both a msrp and rtp.
Showing both the call-window and the chat window (like in the beta) is
confusing for users.
So when message-sdp comes in (or sent out), no call-window is/should be
set-up, just the chat-window (mind you, as a SIP dialog/call it should
be administered as some session/callpeer).
But then an incoming INVITE must be accepted through another (non-call)
pop-up along the lines of "accept <contact> chat [Y/N]?".
I am not sure about this. Have you ever seen any popular 1-2-1 chat
application do this? People don,t ask you permission every time they want
to send you messages on skype, gtalk or facebook. They just do.
We may however want to add something like this for people not on your
roster .. But that would have to be a new mechanism.
Now I have that already if the INVITE is from a chatroom (yes, when the
contact-header indicates ";isfocus" - this lead to a complete conference
call window in the beta where it should really open some chatroom window),
accomplished by firing an InvitationEvent for an ad-hoc chatroom.
Oh my ... You also want to handle MUCs with your first impl? This is
shaping to be quite of a patch and the integration effort may prove to be
Question is, how do I subsequently (on the join) activate the chatroom
window and give it focus within Jitsi? Looks like Jitsi has that already
have problems tracking how that's done (have problems mimicking such
behaviour with IRC/XMPP).
Should happen on the first message IIRC ... But I might be wrong.
Likewise, is there an acceptance pop-up already for a 1-to-1 chat and how
I activate that?
No there isn't. We may consider this for out of roster senders but you can
just accept everyone for starters.
Also, the message-window only pops-up when the first message is received.
Ideally, it should pop-up the moment it is accepted.
Is this what you meant with "conversation management"?
That too yes. Note however, that I wouldn't want empty chatwindows popping
up. I'd rather see them only when I have something to read. We can still
issue a toaster notification like we do for pro-active typing notifications.
Btw.: is there some form of design/UML of the software? Because I find
myself spending an inordinate amount of time figuring out how some stuff
interacts (don't get me wrong, the software seems/is quite structured but
the sheer volume gives it a steep learning-curve).
Well, there's the AOSA book ...but that's all. We are very much open to
contributions in that regard.
> That's why I thought that starting with the file transfer use case
> would be more straight forward, as you have clear begin and end points
My guess is, the same issues will apply. I need the SIP dialog handling
there but not the call-stuff.
As soon as I want to send/receive a file to a contact, acceptance pop-ups
are needed again and possibly auto-popup any file transfer window?
Yes, and all this already exists for file transfers! So I very strongly
believe that this will be easier to write and then easier for is to review
and integrate in Jitsi.
So maybe I need more separation between SIP handling a call and/or chat
As usual, any further hints: much appreciated.
Well, I've been trying to hint ... as hard as I can toward trying FTs first
But basically opset telephony can do the demuxing. It will handle one way
anything that has audio and video (potentially cancelling chats and FTs in
the same request), passing message media to the msrp op set and handling
FTs a third way.
--sent from my mobile
On May 1, 2013 12:32 PM, "Tom Uijldert" <firstname.lastname@example.org> wrote:
> -----Original Message-----
> On 09.04.13, 18:03, Tom Uijldert wrote:
> >> -----Original Message-----