|Re: [ecf-dev] Google Summer Of Code ideas|
Hi Marek, Marek Zawirski wrote:
Hello ECF Team! I'm a student looking for an interesting project for this year Google Summer of Code. I've thought about ECF project and have've seen some cool ideas realized during past GSoCes for ECF:)
Yes, indeed. We've been very lucky to have some great projects...bittorrent provider, sharecode, voip with jingle, real-time shared editing. And these projects have/are finding being added to ECF.
Few words about me, what you could expect: I'm BSc/MSc undergraduate of computer science course at Poznan University of Technology (Poland), quite experienced Java developer with some basic knowledge about Eclipse internals, frameworks, APIs - I've finished workshop (Eclipse Summer School) on developing Eclipse plugins some time ago. My main fields of interests are distributed systems and software engineering. That's how I came here actually... This week was my first direct contact (on-my-screen) with ECF and Mylyn projects - impressing ones! What interest me most in these 2 projects, and where I found some common goals, are ideas how to make distributed development process easier and more fun.
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:
I've seen 2 ideas proposed related to ECF on http://wiki.eclipse.org/Google_Summer_of_Code_2008_Ideas site. I wonder do you have some other ideas that are waiting for some research and/or implementation, another developer? I've been investigating how could I extend this project and I've collected some (more or less) free thoughs/ideas - I'd appreciate your comments on them:) You know your project best for sure and may see whether some idea would be valuable or even possible. Thoughts, ideas: // 0) for memory: here should be few ideas that I've found (un)fortunately already realized in ECF ;) 1) VNC implementation, generally application sharing (also found some info about it here: http://wiki.eclipse.org/Application_Sharing).
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.
It would be nice to have VNC remote application/desktop as Eclipse View, and possibly share this session with other developers - invite them to such session. I can imagine some use cases of application-sharing: software support, debugging sessions or presentations. This is the client side of VNC protocol, application sharing. Another idea is execution of VNC server from Eclipse - for whole desktop or for selected window (possibly external application or Eclipse itsefl). Something more than sharing screenshot of selected area. This could be intersting feature, IMO.
Yes, I agree...this would be a very interesting/useful set of features.
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.
Currently, VNC client plugin for Eclipse exists: VNClipse allowing VNC session to be handled as Eclipse View, but... 1) it seems to be an inactive project 2) there may be license issues 3) it's closed-source(?).
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.
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.
The really problematic matter is running VNC server from Eclipse/SWT. The best thing would be to have own VNC server implementation in pure Java. But there is a problem with capturing desktop/application. I've seen that you can capture screen or part of it from SWT. But can we register our own GC (graphic context or some another SWT object) for whole screen, that capture particular area repaint calls, and delegate these repaints to real GC and VNC server implementation? This would be ideally, but I'm afraid this maybe impossible from pure SWT as it may be low-level and system-specific, isn't it? Another solution are periodical captures of screen/some area, and looking for changes. However, I imagine that there could be serious performance issues making latter solution unuseful one. Another problems are mouse and keyboard capturing of external application window/desktop from SWT. Do you have some experience related to these issues?
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
Eventually, VNC server could be called as external system-specific application (booo) or even there could be no support for executing VNC server.
2) There are some efforts in area of bulletin-board access API and implementations. Have you though about Atom/GData/RSS implementation?
We already have an RSS implementation...although we have not recently been using it. It's in /cvsroot/technology/org.eclipse.ecf/providers/org.eclipse.ecf.provider.rss. I needs a little work/clean up, but is probably in pretty good shape.
BTW, it implements a so-far-little-used part of the ECF datashare API: org.eclipse.ecf.datashare.mergeable to implement the Microsoft RSS SSE protocol (Simple Sharing Extensions).
Also...an ECF committer (Peter Nehrer) has I believe written an Atom implementation...although I don't know what it's status is.
With the work we are doing on real-time shared editing, it would be really interesting to do some work on Atom/GData/RSS publishing.
This may open some other ways, like Calendar access implementations: Goggle Calendar by GData API, some other using transport protocol+ICS format, XML. I believe that such implementations are related to both protocols and file-formats: is it in scope of this framework? I've also seen some efforts for Calendar support in Mylyn project.
That would be really exciting (integration of Google Calendar via GData API).
3) Do current Discovery API implementations allow finding services in local subnet? This could be useful feature for creating ad-hoc environments e.g. on some workshop or meeting.
Yes. We have two providers for the discovery API:
1) Bonjour/zeroconf and2) SLP (service locator protocol rfc 2608). Both of these protocols publish/expose services on a local subnet. For example, see Wayne's blog posting a couple of days ago after my/Markus'/Jan's talk at EclipseCon:
http://dev.eclipse.org/blogs/wayne/2008/03/20/using-ecf-for-lightweight-distributed-team-collaboration/ Here are the presentation slides for my talk: http://www.eclipse.org/ecf/presentations/eclipsecon2008/longtalk134/ecf_eclipsecon2008_134.pdf
4) Development of File-hosting sites API with possibility of uploading files, and sharing URLs (using existing APIs?). Example implementation: rapidshare.com access.
Yes. It might be good to coordinate this with the Eclipse 'Spaces' project: http://www.eclipse.org/spaces. We are already working with them, so this is a natural.
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.
5) Some of your ideas...?
Now that Eclipsecon is over, I will try to post some of my ideas for ECF-based SOC projects for SOC 2008 on the wiki page:
I also wonder what do you assume in ECF: could you relay on someexternal libraries - protocols implementations?
Yes...the protocols do not have to be implemented in java (although this makes it easier clearly). We have a Skype provider here http://ecf1.osuosl.org that uses the native Skype client implementation on whichever platform.
I believe that it may be not easy to create better API and/or implementation in some cases. Or is your main goal to create general API, regardless whether implementations use 3rd parties libraries or not?
Yes...to the latter...our main goal is to create general API, regardless of whether the providers/impls use 3rd party libs or not.
I think that you (Marek) should post these ideas on the Google SOC ideas page:
Back to the top