[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ecf-dev] Google Summer Of Code ideas
|
Thanks for some feedback!
However, I've been hoping that you blame some of these ideas, so you
will leave me with zero, one or two ;) Instead, I have to do some
elimination myself, to focus on narrower set of tasks. I'm planning to
choose a final task I will concentrate on in about 2 days, so I'll
appreciate some comments to help me choose it (what's feasible, what's
not) :)
Sorry for cutting your reply Scott, I will focus on 3 most interesting
tasks for me: VNC, SIP, Mylyn integration. I've done further
investigation only in area of these 3. I won't close other ways, but
that's my pre-selection.
Yes...a worthy goal indeed!
Remy Suen has already done some work on ECF/Mylyn integration...here's a
entry on the mailing list about the work:
http://dev.eclipse.org/mhonarc/lists/ecf-dev/msg01195.html
One possibility is that you take this work and extend it/complete it...I
don't think Remy is actively working on this right now, and I think it's
likely that he would agree to mentor a project using/extending this
code...if you ask really nicely.
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.
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++ ;>
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?).
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... (?)
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.
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? 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.
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?
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?
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?
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?
Around year ago I had some experiences with low level Java Sound API,
and AFAIR it is not very functional. Higher level Java Media Framework
seems to be abandoned by Sun.
I think that you (Marek) should post these ideas on the Google SOC ideas
page:
http://wiki.eclipse.org/Google_Summer_of_Code_2008_Ideas
These are great ideas...thanks very much! I'm looking forward to
working with you!
Nice to hear. I'll just add 2 of them, I've also read your last mail -
no problem with adding them by you of course!
Sorry that it take so long time to answer, I'm little sick and have been
doing some ideas further investigation.
Still waiting for some comments!
Bye,
--
Marek Zawirski [zawir]
marek.zawirski@xxxxxxxxx
