[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ecf-dev] Google Summer Of Code ideas
|
Hi Marek,
[Moritz and Roland...please see below for questions about
SIP/codecs/Java media]
[Mik please see below for questions about Mylyn integration with ECF as
a SOC project]
Marek Zawirski wrote:
1) Mylyn integration
I'm asking really nicely Remy, is it possible at all? :) If not I'm
just leaving you list of some ideas (possibly stupid as I'm not
experienced user of Mylyn).
Major function implemented by Remy is sending tasks between users.
I've thought what could be added and my output is:
a) Chat/call with some user from issue-tracking system, such as bug
reporter, possibly software client, or commenting developer. This is
probably one of most obvious feature, but result in problem of
mapping Issue-Tracking System (let me name it ITS if you don't mind)
users database to IM users list. First, I thought about heuristic
basing on usernames: cliking on username results in Menu "Chat
with..." and possible guesses in your buddy list, or manual user
selection. Such selection could be stored in some mapping, possibly
locally or on ITS. However, I don't now is ITS a good place for such
sensitive data?
When looking for solution, I've found
https://bugs.eclipse.org/bugs/show_bug.cgi?id=152415 which address
this problem and is related to Higgins framework(?). Do somebody know
what's the current status of these issue? I guess it would require
changes in Mylyn itself possibly?
Some generalization of a) would be creating mutliuser chat/conference
for a task. Similar problems I guess + additional issue: multiuser
chat support in ECF providers.
b) Also related to a). Make contacts/communication part of an issue
context. ITS allows to define contacts of a task by providing:
reporter, assigned user (or users, depending on ITS), commenting
users. Is it enough?
This would require Monitoring API implementation or some manual
adding to context(?). As it may be hard to distinct whether such chat
is related to this issue or is it "just" chat with friends during
work, coding same time ;)
However, when somebody is initiating shared editor session, it's
quite sure that this contact is related to this task.
Some contacts may be also extracted from @author tags of javadocs
possibly. That's however, more language and company recommendations
specific, I'm afraid. It's just another way of creating
communication-context which might be seen as general problem.
Anyway, there are still some problems with contacts mapping, as IMHO
it would be better to store them in ITS-usernames form in context
(more general form), and define mappings in other part (as users may
use different IM for example).
Another problem is that creating communication/contacts context in
form of Mylyn context will make it unusable for non-Mylyn ITS users.
c) When having some task-oriented chat with somebody, it mabye useful
to add log from part of conversation to ITS, don't you think? This
may include extended problem recognition after interview with
reporter or implementation status details after chat with developer.
However, it would be nice to do it easily, without too much manual
reformatting, so just selecting some fragment. That's mainly
copy-paste transformation support possibly. That's small feature
possibly.
d) Some fun and maybe not possible;) Real-time task synchronization.
When >= 2 developers work on some task(s) simultaneously and want
online synchronization of their contexts without manual sync. I don't
know Mylyn details yet, especially context model and synchronization
model. So I'm not sure is it possible to create such synchronization
session. This may be a complex one.
I also wonder how much part of implementation of a) - d) or others
require intervention in Mylyn code. Is it in fact ECF project, or
Mylyn project using ECF (is it a problem?)? Possibly not everything
could be done as Mylyn Bridge as my first my guess.
I also wonder how much part of implementation of a) - d) or others
require intervention in Mylyn code. Is it in fact ECF project, or
Mylyn project using ECF (is it a problem?)?
It's not inherently a problem, but would require coordination with Mylyn
team (if it in fact does require changes to Mylyn code as opposed to
additions via further plugins). I've copied Mik Kersten on this email
to get his input on some of the questions you raise.
Possibly not everything could be done as Mylyn Bridge as my first my
guess.
2) VNC
Yes...this would be a terrific project IMHO. The reason we haven't
worked on this so far is captured in a single word: 'resources'. We
just haven't had enough time/interested people to do it.
(possibly) resourcesNumber++ ;>
Sounds great.
What about realization?
I've read about proposed idea to create some interface for application
sharing with VNC as one of implementation, or some existing interfaces
may be used (e.g. ISharedObject?). This could be used for session
sharing possibly. VNC protocol need to be implemented or some external
library used.
Yes. There are different approaches here...one would be to make a
localhost socket connection to a running VNC server/host, and
basically have the ECF host get screen sharing data from localhost,
send it over the wire, and then display on remote clients.
I wonder what is a purpose of making ECF a proxy for real VNC server.
Is it really needed? Do you mean better control or some tunneling
(with encryption?).
Compression, encryption, and/or tunneling certainly can/could be done.
Also, using ECF can distribute the VNC server output to several/group of
receivers.
In simple model VNC server could just listen/bind on * interface, not
only localhost, being more standalone. All what is shared then is some
URL and possibly some settings? This may have some drawbacks maybe... (?)
This would be OK, but it would limit what you can/could do with ECF (on
servers or clients). For example...if you are sending the VNC server
screen output and mouse/keyboard input over ECF provider, then you
can/could have some ways to do a) recording; b) have bots that respond
to certain kinds of mouse/keyboard input...for example.
Some months ago I tried to contact the VNClipse folks to ask them if
they would be interested in working together...and didn't hear
anything back. They may have been busy, or things may have changed,
so it would probably be worthwhile to try to contact them again. I
can't immediately remember what the license was, but at that time
they were not making the source available.
I'll just write to them.
OK, great.
One other licensing issue is that the VNC source itself (including
the java clients) are GPL, so if we want to use/modify any of that
code the resulting code cannot be under the EPL (Eclipse license).
ECF has both EPL-based components (i.e. those hosted/distributed at
dev.eclipse.org), and those *not* under EPL (the 'ECF Extras' hosted
at ecf1.osuosl.org), so we can work around these issues for a SOC
project in any case.
Did you mean TightVNC GPL implementation?
Yes.
I've done some zoom in at its vncviewer code - VNC client. It appears
to be not very very complicated, ~20classes / ~20KLOC. However,
implementation is sticked to AWT/SWING, so would require embedding AWT
Canvas component or forking project and porting it to SWT. In the
latter case, things looks rather straight-forward.
BTW: interesting TightVNC feature is recording of session from client.
Yes.
I personally do not, as I'm not an SWT expert. In other java-based
impls of VNC, we've used the native code impls of VNC and talked to
them via a localhost socket connection as you suggest below (booo)
:). There may very well be ways to write a VNC server in java using
SWT...and given SWT's native implementation it could be sufficiently
performant on some/all platforms. I don't know.
But there are several people on the ECF committer list that are very
good WRT SWT and UI: Boris Bokowski, Remy Suen, Chris Anisczyck and
others. Hopefully we can pull them into the conversation
I'd appreciate your comments:) Things that I'm especially wondering
are they possible:
- is it possible to make SWT "secondary" output to some user-provided
framebuffer class, register some redrawing listener for a whole
desktop, even when non-SWT window is focused?
- is it possible to grab mouse/keyboard input from other windows, even
when non-SWT window is focused?
I doubt it (for both questions), but this is indeed something that
should be asked of SWT experts. Perhaps it would be a good idea to pose
these questions in the SWT newsgroup(s)?
Still, some external native code could be started like with Skype, but
AFAIK VNC servers are provided in different ways and under different
licenses. Eventually it could be configured by user, but what are
Eclipse-embedding benefits then...
BTW What java-based impl did you mean, Scott? Some closed-source?
No, I meant the java client provided with realvnc (I think that's the name).
3) SIP
4) SIP implementation, not yet made for ECF(?). I don't have much
experience (except user-side) with that protocol, just wondering how
laborious this task may be...
This is a great question for our two VOIP committers: Moritz Post
(did the Jingle VOIP SOC project last year), and Roland Fru (has
worked quite a lot with SIP and Asterisk).
In either case I think a SIP provider (implementer of the ECF call
API) would be great.
Ok, again, I'm asking kindly for some comments:)
I've found JAIN SIP API and reference implementation of SIP and SDP,
made as part of Java Specification Request. However, I've read it is
bit outdated, on JSDP page - don't know how/why. JSDP is unofficial
(out of JSR) implementation od SDP. Basic signaling part of this
project may be not very hard. I'm expecting more problems with
interoperability and mainly - transport/RTP and codecs/audio
implementations.
Or do you have other experiences?
I'm forwarding this onto Moritz Post, who did the 2007 VOIP project
(Jingle). He ended up using Java Media codecs/audio implementations to
do this, as I expect that's what the JAIN sip implementation does. I've
noticed that the JAIN SIP implementation doesn't seem to be getting a
lot of new work recently, so I'm not sure of it's status. Moritz and
Roland please comment about existing SIP implementations that you know
about.
The codecs, audio, RTP part may be already implemented as part of
Moritz Post GSoC work possibly(?). AFAIK jingle is just another
signaling protocol with similar role as SIP with SDP, so maybe audio,
compression and streaming code may be shared?
That is very possible. I'll let Moritz and Roland answer your questions
more directly.
Thanks,
Scott
