I don't know SIP communicator much, and especially haven't looked at the GUI
part, so I'm not really qualified to say which would be the best approach.
I'll try anyway
I think that, from the GUI point of view, the video image has to be
associated with the CallParticipant who is shown. This way, when there is a
conference call or multiple simultaneous calls, the GUI can show the name of
the caller. Since the incoming media is thus associated with the
CallParticipant, a media listener which can be registered on objects of that
class may be useful. It would make the implementation kind of difficult,
since the component has to be passed from media to protocol, and from there
Your solution 1 (extending the CallSession interface) has the drawback that
the interface is currently used for the low-level tasks like handling the
SDP data, which the GUI usually doesn't care about. I don't know if the GUI
currently uses the media bundle directly at all?
Solutions 2 and 3 add more GUI knowledge to the media bundle. Of course I'm
not the one to make the decisions, but for me it doesn't feel right. On the
other hand, audio rendering and control is also done in media, so perhaps it
would not be too bad after all.
On UI lib independence, I think it is also a matter of what the media
library supplies to the media bundle. The players of JMF and FMJ both use
some java.awt.Component subclass (I think), so I guess that is all SIP
communicator needs to support. Since java.awt.Component has been part of
Java since 1.0, I guess all alternative GUI libraries will support it in
I don't know what would be the best approach. One probably has to think
about the GUI for video calls first, and then decide how the needed
information is best passed from back-end to front-end. If someone wants to
do this part, I could help out with the back-end implementation. For my
short-term needs, I have extended the MediaEvent/MediaListener mechanism
which was already there and pass the component around in the event. I don't
know if this is such a good solution, because:
* I'm not sure if I am using the event for the purpose it was intended for
* It hooks the GUI directly to the media bundle, which I don't know if this
is supposed to be done
but it works for me
(I could create a patch if there is interest).
Right now the media service is simply popping out a frame
video flow. I guess you've noticed this already. This of
course is only
temporary and we'll have to think of a more elaborate way to handle it
in the future.
Possible solutions may include:
1. Adding a method to CallSession that allows it to return a visual
component that the UI (or any other bundle) would be able to
would also have to add methods that would allow users to register
listeners and get notified when such a component becomes available.
(Pretty much the way things work with the JMF Player interface)
2. Allowing other modules to register container components where the
media service would be supposed render all visual content.
3. Do not pass components across modules, and instead, define
an API in
CallSession that would give you some control over its visual
(move, resize, dock).
The tricky part for 1 and 2 is how to handle this in a way that is
independent from a particular UI lib. I don't really see a
way to do so
unless we settle for AWT components and hope that they will
by other UI libs (which is the case with swing and swt)
3 on the other hand, would give us the independence but would
add a lot
of complexity to the implementation of Call Sessions.
Personally, I am not sure which is the best way to go. Do you have any