https://wiki.eclipse.org/api.php?action=feedcontributions&user=Codesurgeon.gmail.com&feedformat=atomEclipsepedia - User contributions [en]2024-03-28T08:19:20ZUser contributionsMediaWiki 1.26.4https://wiki.eclipse.org/index.php?title=ECF_Documentation_Priorities&diff=231257ECF Documentation Priorities2010-12-12T16:41:33Z<p>Codesurgeon.gmail.com: Added myself to Docshare/Cola and Wave</p>
<hr />
<div>==Introduction==<br />
<br />
Below is an in-progress list areas where ECF documentation is needed. They are not yet in any particular order. Next to each one is a count to indicate how many people are interested in seeing documentation in that area. Please feel free to add 1 to the count for the areas that you think are important to you. Please do not change the counts other than to add one to the areas you feel are most important for you.<br />
<br />
==Documentation Area==<br />
<br />
OSGi Remote Services - 4<br />
<br />
Core API - 3<br />
<br />
Containers - 3<br />
<br />
ECF Providers - 3<br />
<br />
OSGi Remote Service Admin - 3<br />
<br />
Remote Services API - 3<br />
<br />
Discovery API - 3<br />
<br />
Shared Object API - 2<br />
<br />
Datashare API - 2<br />
<br />
Presence API - 2<br />
<br />
Discovery Providers - 2<br />
<br />
Asynchronous Remote Services - 3<br />
<br />
ECF Generic Provider - 3<br />
<br />
r-OSGi Provider - 2<br />
<br />
REST and ECF Remote Services - 2<br />
<br />
ECF Architecture - 3<br />
<br />
XMPP Provider - 2<br />
<br />
ECF SIP Provider - 2<br />
<br />
JavaGroups Provider - 2<br />
<br />
Encryption - 1<br />
<br />
Async File Transfer API - 1<br />
<br />
Authentication - 1<br />
<br />
Telephony API - 2<br />
<br />
General Distributed Systems Issues (e.g. reliability, transparency) - 1<br />
<br />
Remote Services Authorization - 1<br />
<br />
ECF on Servers - 2<br />
<br />
Load Balancing Using Remote Services - 1<br />
<br />
JMS Provider - 1<br />
<br />
Remote Management - 1<br />
<br />
Other Providers - 1<br />
<br />
Extensibility - 2<br />
<br />
Testing - 1<br />
<br />
Release Engineering - 1<br />
<br />
TweetHub - 1<br />
<br />
Wave Provider - 2<br />
<br />
Docshare/Cola - 3<br />
<br />
ECF Distros (e.g. p2 repos, jars, Maven, etc) - 2<br />
<br />
<br />
<please add others here></div>Codesurgeon.gmail.comhttps://wiki.eclipse.org/index.php?title=Google_Wave_ECF_provider&diff=206974Google Wave ECF provider2010-06-17T08:08:18Z<p>Codesurgeon.gmail.com: added information to our dev sync up meeting on Tuesdays</p>
<hr />
<div>Student: Sebastian Schmidt<br />
<br />
Mentor: [http://codesurgeon.com Mustafa K. Isik]<br />
<br />
This project is part of the [[Google Summer of Code 2010]] <br />
<br />
== Abstract ==<br />
<br />
[http://wave.google.com Google Wave] is a real-time collaboration system based upon operational transformation approach to replicated state synchronization. With the Cola System (DocShare), ECF has been using operational transformations, for some time now. I will implement a provider to allow an equinox+ecf based web server to inter-operate with Google Wave. <br />
<br />
== Primary goals ==<br />
<br />
<div style="border: 1px solid rgb(170, 170, 170); margin: 0pt 0pt 1em 1em; padding: 4px; background: rgb(249, 249, 249) none repeat scroll 0% 0%; clear: right; font-size: 90%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous; width: 250px; text-align: left; float: right;"><br />
'''Legend''' <br> [[Image:Glass.gif]] Needs some research <br />
<br />
[[Image:Progress.gif]] Work in progress <br />
<br />
[[Image:Ok green.gif]] Feature added <br />
</div> <br />
<br />
[[Image:Progress.gif]] Implementation of a Google Wave ECF provider<br />
that people can use to build their own wave applications on top of<br />
ECF. The provider will handle the basic wave-protocol operations like<br />
managing waves, contacts and documents. Also the provider will provide<br />
an API which allows users to add listeners to wave changes and<br />
implement real time shared editing applications.<br><br><br />
[[Image:Glass.gif]] Implementation of real time shared editing support<br />
for eclipse. Currently there are<br />
[http://www.youtube.com/watch?v=GfeUCT-tRJQ cola and docshare], which<br />
allow document based real time shared editing for two collaborators in<br />
eclipse. With the help of the wave protocol I want to improve this<br />
approach and allow more than two collaborators to work on one document<br />
at the same time. Once you logged into your wave account using the well known ECF<br />
UI, you will be able to share a text-based document for collaborative<br />
editing with your friends on your or any standards compliant third-party wave server. Currently, Google does not provide API access to their official Wave service, their developer sandbox remains open though and can be utilized in scenarios where another Wave server is not available. It is likely that ECF will have its own instance of a free-for-all Wave server running.<br />
<br />
== On the horizon ==<br />
In their GSoC welcome package Google told us to "think big and have<br />
fun". That's why Mustafa and I already have spoken about ideas we have for the<br />
time after the end of GSoC 2010. The wave protocol allows to<br />
handle more than a single document (= wavelet / blips) in a wave. With an appropriate mapping of Wave components such as Waves to projects and Wavelet/Blips to resources such as sourcecode files, this<br />
feature can be adopted to introduce project-based real time shared<br />
editing to eclipse. Hopefully we will be able to share a complete<br />
project with fellow developers at some point and collaborate with them on multiple files and folders in real time.<br />
<br />
I would really appreciate to get inspiring ideas from the<br />
community. So please feel free to provide feedback and share your<br />
[http://wiki.eclipse.org/Google_Wave_ECF_provider#New_ideas ideas].<br />
<br />
== Timeline ==<br />
{| class="wikitable" style="text-align: center;"<br />
|- style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;"<br />
! Milestone <br />
! Date <br />
! Planned/Completed/Progressing&nbsp; items <br />
! status<br />
|- style="background: lightgrey none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;"<br />
! M1 <br />
| May 5<br />
| align="left" | research and planning<br />
| [[Image:Ok green.gif]]<br />
|- style="background: lightgrey none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;"<br />
! M2<br />
| July 1<br />
| align="left" | ecf wave provider implementation<br />
| [[Image:Progress.gif]]<br />
|- style="background: lightgrey none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;"<br />
! M3<br />
| TBD<br />
| align="left" | real time shared editing for eclipse (basic version: one document, multiple collaborators)<br />
| [[Image:Glass.gif]]<br />
|- style="background: lightgrey none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;"<br />
! M4<br />
| TBD<br />
| align="left" | bughunting, documentation<br />
| [[Image:Glass.gif]]<br />
|- style="background: lightgrey none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;"<br />
|}<br />
=== Meetings ===<br />
In addition to the weekly [http://wiki.eclipse.org/index.php/Eclipse_Communication_Framework_Project ECF conference call on Mondays], both of us will be syncing up via another call Tuesdays around 11:30AM PST - that is 20:30h in Germany. Feel free to join us. In order to do so, you'll have to either ping Sebastian or Mustafa (''codesurgeon'') via Skype chat. You'll be invited to the conference call.<br />
<br />
== Getting the source ==<br />
<br />
The Wave provider is hosted at ecf1.osuosl.org. Detailed information is provided on [https://bugs.eclipse.org/bugs/show_bug.cgi?id=280347#c10 the enhancement request]. The sourcecode is also [http://github.com/sschmidt/eclipse-ecf-wave mirrored on github.com] to facilitate collaboration via the Git version control system and github features.<br />
<br />
== Open issues ==<br />
To see all the open issues and feature requests of this project, take a look at [https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;short_desc=wave;short_desc_type=allwordssubstr;component=ecf.providers this Bugzilla query].<br />
<br />
== New ideas ==<br />
Do you have a great idea for the provider? Just open a [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=ECF new feature request] or comment on the existing [https://bugs.eclipse.org/bugs/show_bug.cgi?id=280347 enhancement request].<br />
<br />
<br />
[[Category:SOC]]</div>Codesurgeon.gmail.comhttps://wiki.eclipse.org/index.php?title=Google_Wave_ECF_provider&diff=206973Google Wave ECF provider2010-06-17T07:57:00Z<p>Codesurgeon.gmail.com: mentioned mapping of wave software components to eclipse project resources, minor other changes</p>
<hr />
<div>Student: Sebastian Schmidt<br />
<br />
Mentor: [http://codesurgeon.com Mustafa K. Isik]<br />
<br />
This project is part of the [[Google Summer of Code 2010]] <br />
<br />
== Abstract ==<br />
<br />
[http://wave.google.com Google Wave] is a real-time collaboration system based upon operational transformation approach to replicated state synchronization. With the Cola System (DocShare), ECF has been using operational transformations, for some time now. I will implement a provider to allow an equinox+ecf based web server to inter-operate with Google Wave. <br />
<br />
== Primary goals ==<br />
<br />
<div style="border: 1px solid rgb(170, 170, 170); margin: 0pt 0pt 1em 1em; padding: 4px; background: rgb(249, 249, 249) none repeat scroll 0% 0%; clear: right; font-size: 90%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous; width: 250px; text-align: left; float: right;"><br />
'''Legend''' <br> [[Image:Glass.gif]] Needs some research <br />
<br />
[[Image:Progress.gif]] Work in progress <br />
<br />
[[Image:Ok green.gif]] Feature added <br />
</div> <br />
<br />
[[Image:Progress.gif]] Implementation of a Google Wave ECF provider<br />
that people can use to build their own wave applications on top of<br />
ECF. The provider will handle the basic wave-protocol operations like<br />
managing waves, contacts and documents. Also the provider will provide<br />
an API which allows users to add listeners to wave changes and<br />
implement real time shared editing applications.<br><br><br />
[[Image:Glass.gif]] Implementation of real time shared editing support<br />
for eclipse. Currently there are<br />
[http://www.youtube.com/watch?v=GfeUCT-tRJQ cola and docshare], which<br />
allow document based real time shared editing for two collaborators in<br />
eclipse. With the help of the wave protocol I want to improve this<br />
approach and allow more than two collaborators to work on one document<br />
at the same time. Once you logged into your wave account using the well known ECF<br />
UI, you will be able to share a text-based document for collaborative<br />
editing with your friends on your or any standards compliant third-party wave server. Currently, Google does not provide API access to their official Wave service, their developer sandbox remains open though and can be utilized in scenarios where another Wave server is not available. It is likely that ECF will have its own instance of a free-for-all Wave server running.<br />
<br />
== On the horizon ==<br />
In their GSoC welcome package Google told us to "think big and have<br />
fun". That's why Mustafa and I already have spoken about ideas we have for the<br />
time after the end of GSoC 2010. The wave protocol allows to<br />
handle more than a single document (= wavelet / blips) in a wave. With an appropriate mapping of Wave components such as Waves to projects and Wavelet/Blips to resources such as sourcecode files, this<br />
feature can be adopted to introduce project-based real time shared<br />
editing to eclipse. Hopefully we will be able to share a complete<br />
project with fellow developers at some point and collaborate with them on multiple files and folders in real time.<br />
<br />
I would really appreciate to get inspiring ideas from the<br />
community. So please feel free to provide feedback and share your<br />
[http://wiki.eclipse.org/Google_Wave_ECF_provider#New_ideas ideas].<br />
<br />
== Timeline ==<br />
{| class="wikitable" style="text-align: center;"<br />
|- style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;"<br />
! Milestone <br />
! Date <br />
! Planned/Completed/Progressing&nbsp; items <br />
! status<br />
|- style="background: lightgrey none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;"<br />
! M1 <br />
| May 5<br />
| align="left" | research and planning<br />
| [[Image:Ok green.gif]]<br />
|- style="background: lightgrey none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;"<br />
! M2<br />
| July 1<br />
| align="left" | ecf wave provider implementation<br />
| [[Image:Progress.gif]]<br />
|- style="background: lightgrey none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;"<br />
! M3<br />
| TBD<br />
| align="left" | real time shared editing for eclipse (basic version: one document, multiple collaborators)<br />
| [[Image:Glass.gif]]<br />
|- style="background: lightgrey none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;"<br />
! M4<br />
| TBD<br />
| align="left" | bughunting, documentation<br />
| [[Image:Glass.gif]]<br />
|- style="background: lightgrey none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;"<br />
|}<br />
<br />
<br />
<br />
== Getting the source ==<br />
<br />
The Wave provider is hosted at ecf1.osuosl.org. Detailed information is provided on [https://bugs.eclipse.org/bugs/show_bug.cgi?id=280347#c10 the enhancement request]. The sourcecode is also [http://github.com/sschmidt/eclipse-ecf-wave mirrored on github.com] to facilitate collaboration via the Git version control system and github features.<br />
<br />
== Open issues ==<br />
To see all the open issues and feature requests of this project, take a look at [https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;short_desc=wave;short_desc_type=allwordssubstr;component=ecf.providers this Bugzilla query].<br />
<br />
== New ideas ==<br />
Do you have a great idea for the provider? Just open a [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=ECF new feature request] or comment on the existing [https://bugs.eclipse.org/bugs/show_bug.cgi?id=280347 enhancement request].<br />
<br />
<br />
[[Category:SOC]]</div>Codesurgeon.gmail.comhttps://wiki.eclipse.org/index.php?title=Google_Wave_ECF_provider&diff=206972Google Wave ECF provider2010-06-17T07:51:24Z<p>Codesurgeon.gmail.com: minor fixes and information on open Wave server availability</p>
<hr />
<div>Student: Sebastian Schmidt<br />
<br />
Mentor: [http://codesurgeon.com Mustafa K. Isik]<br />
<br />
This project is part of the [[Google Summer of Code 2010]] <br />
<br />
== Abstract ==<br />
<br />
[http://wave.google.com Google Wave] is a real-time collaboration system based upon operational transformation approach to replicated state synchronization. With the Cola System (DocShare), ECF has been using operational transformations, for some time now. I will implement a provider to allow an equinox+ecf based web server to inter-operate with Google Wave. <br />
<br />
== Primary goals ==<br />
<br />
<div style="border: 1px solid rgb(170, 170, 170); margin: 0pt 0pt 1em 1em; padding: 4px; background: rgb(249, 249, 249) none repeat scroll 0% 0%; clear: right; font-size: 90%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous; width: 250px; text-align: left; float: right;"><br />
'''Legend''' <br> [[Image:Glass.gif]] Needs some research <br />
<br />
[[Image:Progress.gif]] Work in progress <br />
<br />
[[Image:Ok green.gif]] Feature added <br />
</div> <br />
<br />
[[Image:Progress.gif]] Implementation of a Google Wave ECF provider<br />
that people can use to build their own wave applications on top of<br />
ECF. The provider will handle the basic wave-protocol operations like<br />
managing waves, contacts and documents. Also the provider will provide<br />
an API which allows users to add listeners to wave changes and<br />
implement real time shared editing applications.<br><br><br />
[[Image:Glass.gif]] Implementation of real time shared editing support<br />
for eclipse. Currently there are<br />
[http://www.youtube.com/watch?v=GfeUCT-tRJQ cola and docshare], which<br />
allow document based real time shared editing for two collaborators in<br />
eclipse. With the help of the wave protocol I want to improve this<br />
approach and allow more than two collaborators to work on one document<br />
at the same time. Once you logged into your wave account using the well known ECF<br />
UI, you will be able to share a text-based document for collaborative<br />
editing with your friends on your or any standards compliant third-party wave server. Currently, Google does not provide API access to their official Wave service, their developer sandbox remains open though and can be utilized in scenarios where another Wave server is not available. It is likely that ECF will have its own instance of a free-for-all Wave server running.<br />
<br />
== On the horizon ==<br />
In their GSoC welcome package Google told us to "think big and have<br />
fun". That's why Mustafa and I already have spoken about ideas we have for the<br />
time after the end of GSoC 2010. The wave protocol allows to<br />
handle more than one document (= wavelet / blips) in a wave. This<br />
feature can be adopted to introduce project-based real time shared<br />
editing to eclipse. Hopefully we will be able to share a complete<br />
project with our colleagues at some time and work with them<br />
collaborative on multiple files and folders in real time.<br />
<br />
I would really appreciate to get inspiring ideas from the<br />
community. So please feel free to report your<br />
[http://wiki.eclipse.org/Google_Wave_ECF_provider#New_ideas ideas].<br />
<br />
== Timeline ==<br />
{| class="wikitable" style="text-align: center;"<br />
|- style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;"<br />
! Milestone <br />
! Date <br />
! Planned/Completed/Progressing&nbsp; items <br />
! status<br />
|- style="background: lightgrey none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;"<br />
! M1 <br />
| May 5<br />
| align="left" | research and planning<br />
| [[Image:Ok green.gif]]<br />
|- style="background: lightgrey none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;"<br />
! M2<br />
| July 1<br />
| align="left" | ecf wave provider implementation<br />
| [[Image:Progress.gif]]<br />
|- style="background: lightgrey none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;"<br />
! M3<br />
| TBD<br />
| align="left" | real time shared editing for eclipse (basic version: one document, multiple collaborators)<br />
| [[Image:Glass.gif]]<br />
|- style="background: lightgrey none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;"<br />
! M4<br />
| TBD<br />
| align="left" | bughunting, documentation<br />
| [[Image:Glass.gif]]<br />
|- style="background: lightgrey none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;"<br />
|}<br />
<br />
<br />
<br />
== Getting the source ==<br />
<br />
The Wave provider is hosted at ecf1.osuosl.org. Detailed information is provided on [https://bugs.eclipse.org/bugs/show_bug.cgi?id=280347#c10 the enhancement request]. The sourcecode is also [http://github.com/sschmidt/eclipse-ecf-wave mirrored on github.com] to facilitate collaboration via the Git version control system and github features.<br />
<br />
== Open issues ==<br />
To see all the open issues and feature requests of this project, take a look at [https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;short_desc=wave;short_desc_type=allwordssubstr;component=ecf.providers this Bugzilla query].<br />
<br />
== New ideas ==<br />
Do you have a great idea for the provider? Just open a [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=ECF new feature request] or comment on the existing [https://bugs.eclipse.org/bugs/show_bug.cgi?id=280347 enhancement request].<br />
<br />
<br />
[[Category:SOC]]</div>Codesurgeon.gmail.comhttps://wiki.eclipse.org/index.php?title=ECF_Conference_Call_6.14.2010&diff=206008ECF Conference Call 6.14.20102010-06-14T17:17:35Z<p>Codesurgeon.gmail.com: updated attendee list</p>
<hr />
<div>==Attendees==<br />
Markus A. Kuppe, Mustafa K. Isik, Sebastian Schmidt, Wim Jongman<br />
<br />
==Agenda==<br />
<br />
===ECF Releng for Helios===<br />
<br />
====Release_3_3 branch builder status (and HEAD availability for 3.4 work)====<br />
<br />
===CVS to git move===<br />
<br />
*http://wiki.eclipse.org/Git/Migrating_to_Git<br />
<br />
===GSoC status update===</div>Codesurgeon.gmail.comhttps://wiki.eclipse.org/index.php?title=Google_Wave_ECF_provider&diff=202226Google Wave ECF provider2010-05-24T18:28:18Z<p>Codesurgeon.gmail.com: added a couple of links and github reference</p>
<hr />
<div>Student: Sebastian Schmidt<br />
<br />
Mentor: [http://codesurgeon.com Mustafa K. Isik]<br />
<br />
This project is part of the [[Google Summer of Code 2010]] <br />
<br />
== Abstract ==<br />
<br />
[http://wave.google.com Google Wave] is a real-time collaboration system based upon operational transformation approach to replicated state synchronization. With the Cola System (DocShare), ECF has been using operational transformations, for some time now. I will implement a provider to allow an equinox+ecf based web server to inter-operate with Google Wave. <br />
<br />
== Primary goals ==<br />
<br />
<div style="border: 1px solid rgb(170, 170, 170); margin: 0pt 0pt 1em 1em; padding: 4px; background: rgb(249, 249, 249) none repeat scroll 0% 0%; clear: right; font-size: 90%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous; width: 250px; text-align: left; float: right;"><br />
'''Legend''' <br> [[Image:Glass.gif]] Needs some research <br />
<br />
[[Image:Progress.gif]] Work in progress <br />
<br />
[[Image:Ok green.gif]] Feature added <br />
</div> <br />
<br />
[[Image:Glass.gif]] incorporate waveprotocol.org code into ECF code, api-level ECF-provider implementation<br><br />
[[Image:Glass.gif]] example applications for communication between Wave and Eclipse/ECF <br />
<br />
== Timeline ==<br />
{| class="wikitable" style="text-align: center;"<br />
|- style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;"<br />
! Milestone <br />
! Date <br />
! Planned/Completed/Progressing&nbsp; items <br />
! status<br />
|- style="background: lightgrey none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;"<br />
! M1 <br />
| May 5<br />
| align="left" | research and planning<br />
| [[Image:Progress.gif]]<br />
|- style="background: lightgrey none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;"<br />
|}<br />
<br />
<br />
<br />
== Getting the source ==<br />
<br />
The Wave provider is hosted at ecf1.osuosl.org. Detailed information is provided on [https://bugs.eclipse.org/bugs/show_bug.cgi?id=280347#c10 the enhancement request] The sourcecode is also [http://github.com/sschmidt/eclipse-ecf-wave mirrored on github.com] to facilitate collaboration via the Git version control system and github features.<br />
<br />
== Open issues ==<br />
To see all the open issues and feature requests of this project, take a look at [https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;short_desc=wave;short_desc_type=allwordssubstr;component=ecf.providers this Bugzilla query].<br />
<br />
== New ideas ==<br />
Do you have a great idea for the provider? Just open a [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=ECF new feature request] or comment on the existing [https://bugs.eclipse.org/bugs/show_bug.cgi?id=280347 enhancement request].<br />
<br />
<br />
[[Category:SOC]]</div>Codesurgeon.gmail.comhttps://wiki.eclipse.org/index.php?title=Eclipse_Communication_Framework_Project&diff=146870Eclipse Communication Framework Project2009-03-30T07:25:32Z<p>Codesurgeon.gmail.com: /* ECF at EclipseCon 2009 */ added activities list</p>
<hr />
<div>{{Infobox<br />
| name = Eclipse Communication Framework<br />
| download = http://www.eclipse.org/ecf/downloads.php<br />
| website = http://www.eclipse.org/ecf<br />
| list = ecf-dev<br />
| newsgroup = eclipse.technology.ecf<br />
| product = ECF<br />
| irc = eclipse-ecf<br />
| viewvc = org.eclipse.ecf/?root=RT_Project<br />
| psf = http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.ecf/releng/org.eclipse.ecf.releng/projectSet-anonymous.psf?root=RT_Project&view=co<br />
}}<br />
[http://www.eclipse.org/ecf/dev_resources.php ECF Developer Resources (CVS access, newsgroup/mailing list access, etc.)]<br/><br />
<br />
==ECF Conference Calls==<br />
<br />
ECF has weekly conference calls to discuss current and future issues on our roadmap. Anyone is welcome to join us.<br />
*International: 613-287-8000<br />
*Toll free: 866-362-7064<br />
*Participant passcode: 892048#<br />
<br />
===Next Conference Call: Thurs, Mar 19, 2008 1500 UTC NOTE: CANCELLED. WILL BE RESCHEDULED AFTER ECLIPSECON===<br />
<br />
[http://www.timeanddate.com/worldclock/fixedtime.html?year=2009&month=03&day=19&hour=15&min=00&sec=0 Mar 3, 2009, 8:00am pacific time/1500 UTC]<br />
<br />
[http://www.google.com/calendar/embed?src=q0gpojsaatmup0uilkklpe409c%40group.calendar.google.com&ctz=America/Los_Angeles Google Calendar]<br />
<br />
[[ECF Conference Call 3.19.2009|3.19.2009 Call Agenda/Notes]]<br />
<br />
*[[ECF Meeting Notes|Notes from Previous Meetings]]<br />
<br />
===Public and Private Chat Groups===<br />
ECF also has ongoing public and private chat groups. Please join us!<br />
<br />
*IRC (public): <b>irc.freenode.net</b> channel: <b>#eclipse-ecf</b> ECF URL <b>[irc://irc.freenode.net/#eclipse-ecf irc://<user>@irc.freenode.net/#eclipse-ecf]</b><br><br />
*XMPP (private): <b><user>@ecf.eclipse.org</b> multi-user chat: <b>ecf</b><br><br />
*ECF Generic (public): <b>ecftcp://ecf.eclipse.org:3282/server</b><br />
<br />
==Project Planning==<br />
<br />
[http://www.eclipse.org/projects/project-plan.php?projectid=rt.ecf ECF Project Galileo Plan]<br />
<br />
[[ECF 2.1 Release Testing]]<br />
<br />
[[ECF 4.0 ToDo collection]]<br />
<br />
==New Stuff==<br />
<br />
[[Comments on the Riena Project Goals and Relationship to ECF project]]<br />
<br />
[[ECF Connection Creation and Management]]<br />
<br />
[[Extending Real-Time Shared Editing for Use with Other Editors]]<br />
<br />
[[Remote_Eclipse_RCP_Management | Remote Eclipse RCP Management]]<br />
<br />
[[DocShare Plugin|Real-Time Shared Editing]]<br />
<br />
[[Storage/Retrieval of IDs, IContainers using Equinox Secure Preferences]]<br />
<br />
[[Discovery of Remote Services]]<br />
<br />
[[Screen Captures over IM]]<br />
<br />
[[Integration with Mylyn]]<br />
<br />
[[Sharing Editor Selections]]<br />
<br />
[[ECF/REST_abstraction|REST abstraction (H. Staudacher)]]<br />
<br />
[[ECF/REST_ECF|REST abstraction (S. Gandhi)]]<br />
<br />
==ECF Adopters==<br />
<br />
[[ECF/Adopters|ECF Adopters List (please add yourself if you are using ECF)]]<br />
<br />
==Coding Conventions==<br />
<br />
ECF has decided to use the [http://www.eclipse.org/equinox/documents/coding.php Equinox Coding Conventions]. Also [http://www.eclipse.org/equinox/documents/coding.php on this page] are links to java<br />
source code formatter to use in Eclipse to easily enforce these conventions.<br />
<br />
==ECF at Eclipse Summit Europe 2006==<br />
[[Image:Eclipsesummiteurope2006.JPG|right|thumb|300px|From left to right: Roland Fru, Scott Lewis, and Mustafa Isik]]<br />
Check out these guys. They look happy to be working on Eclipse and ECF, no?<br />
<br />
Also see the [http://www.eclipsecon.org/summiteurope2006/index.php?page=detail/&id=35 ECF presentation] given at [http://www.eclipsecon.org/summiteurope2006 Eclipse Summit Europe 2006].<br />
<br />
<br />
==ECF at Eclipse Summit Europe 2008==<br />
<br />
[[ECF at Eclipse Summit Europe 2008 | Take a look at ECF on Eclipse Summit Europe 2008]]<br />
<br />
==ECF at EclipseCon 2009==<br />
[[Image:Eclipsecon2009_ecf_team.JPG|left|thumb|300px|From left to right: Scott Lewis, Mustafa Isik and Markus Kuppe]]<br />
ECF was busy at EclipseCon 2009, giving a number of talks and tutorials. The photo shows Scott, Mustafa and Markus wrapping up the conference at the Hyatt Bar, which is adjacent to the Santa Clara Convention Center.<br />
For your convenience, here is a short overview of ECF activities at EclipseCon 2009:<br />
*[http://www.eclipsecon.org/2009/sessions?id=429 Cola: Real-Time Shared Editing with ECF - Striding towards the Future, Multiple Edits at a Time]<br />
*[http://www.eclipsecon.org/2009/sessions?id=633 Best Practices for Distributed OSGi Services]<br />
*[http://www.eclipsecon.org/2009/sessions?id=618 Distributed OSGi - the ECF way]<br />
*[http://www.eclipsecon.org/2009/sessions?id=772 ECF BoF]<br />
For those who couldn't make it, if the [http://search.twitter.com/search?q=%23eclipsecon busyness during the conference] is to serve as an indicator, you can expect a flurry of post-con blog posts and tweets to show up, giving you an idea of what EclipseCon 2009 was like.<br />
<br />
==Documentation==<br />
<br />
*[[ECF Documentation|Documentation: Intro Docs/Examples, Tutorials, Screencasts]]<br />
*[[ECF API Docs]]<br />
<br />
==Current Projects==<br />
<br />
===Components===<br />
*[[ECF Servers|Servers]]<br />
*[[DocShare Plugin | Cola/Realtime Shared Editing]]<br />
*[[Skype Provider|Skype Provider]]<br />
*[[VOIP|VOIP/Asterisk/Jingle/Call API]]<br />
*[[ECF Remote Services|Remote Services]]<br />
*[[ECF Bulletin Board Providers|Bulletin Board Providers]]<br />
<br />
===API===<br />
*[[ECF API Docs]]<br />
*[[Bot Framework]]<br />
*[[ECF Providers|Providers]]<br />
<br />
===Build===<br />
*[http://wiki.eclipse.org/images/b/b3/AutoBuild001.pdf ECF Build Part 1]<br />
*[http://wiki.eclipse.org/images/7/75/AutoBuild002.pdf ECF Build Part 2] (includes jar signing)<br />
*[http://wiki.eclipse.org/images/4/4a/IntegrationBuilds001.pdf Integration Builds]<br />
<br />
*[[How to VNC to ecf2]]<br />
*Automated Testing<br />
<br />
===Others===<br />
*[[Multi-User Sudoku]]<br />
*[[OLSR provider for ECF]]<br />
*[[Sharing objects over XMPP]]<br />
*[[ECF Apache Httpclient-Based Provider]]<br />
*[[JXTA provider for ECF]]<br />
<br />
{{ECF}}<br />
[[Category:Eclipse Communication Framework]]<br />
[[Category:Eclipse Technology Project]]</div>Codesurgeon.gmail.comhttps://wiki.eclipse.org/index.php?title=Eclipse_Communication_Framework_Project&diff=146869Eclipse Communication Framework Project2009-03-30T07:18:18Z<p>Codesurgeon.gmail.com: /* ECF at EclipseCon 2009 */ reformatting</p>
<hr />
<div>{{Infobox<br />
| name = Eclipse Communication Framework<br />
| download = http://www.eclipse.org/ecf/downloads.php<br />
| website = http://www.eclipse.org/ecf<br />
| list = ecf-dev<br />
| newsgroup = eclipse.technology.ecf<br />
| product = ECF<br />
| irc = eclipse-ecf<br />
| viewvc = org.eclipse.ecf/?root=RT_Project<br />
| psf = http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.ecf/releng/org.eclipse.ecf.releng/projectSet-anonymous.psf?root=RT_Project&view=co<br />
}}<br />
[http://www.eclipse.org/ecf/dev_resources.php ECF Developer Resources (CVS access, newsgroup/mailing list access, etc.)]<br/><br />
<br />
==ECF Conference Calls==<br />
<br />
ECF has weekly conference calls to discuss current and future issues on our roadmap. Anyone is welcome to join us.<br />
*International: 613-287-8000<br />
*Toll free: 866-362-7064<br />
*Participant passcode: 892048#<br />
<br />
===Next Conference Call: Thurs, Mar 19, 2008 1500 UTC NOTE: CANCELLED. WILL BE RESCHEDULED AFTER ECLIPSECON===<br />
<br />
[http://www.timeanddate.com/worldclock/fixedtime.html?year=2009&month=03&day=19&hour=15&min=00&sec=0 Mar 3, 2009, 8:00am pacific time/1500 UTC]<br />
<br />
[http://www.google.com/calendar/embed?src=q0gpojsaatmup0uilkklpe409c%40group.calendar.google.com&ctz=America/Los_Angeles Google Calendar]<br />
<br />
[[ECF Conference Call 3.19.2009|3.19.2009 Call Agenda/Notes]]<br />
<br />
*[[ECF Meeting Notes|Notes from Previous Meetings]]<br />
<br />
===Public and Private Chat Groups===<br />
ECF also has ongoing public and private chat groups. Please join us!<br />
<br />
*IRC (public): <b>irc.freenode.net</b> channel: <b>#eclipse-ecf</b> ECF URL <b>[irc://irc.freenode.net/#eclipse-ecf irc://<user>@irc.freenode.net/#eclipse-ecf]</b><br><br />
*XMPP (private): <b><user>@ecf.eclipse.org</b> multi-user chat: <b>ecf</b><br><br />
*ECF Generic (public): <b>ecftcp://ecf.eclipse.org:3282/server</b><br />
<br />
==Project Planning==<br />
<br />
[http://www.eclipse.org/projects/project-plan.php?projectid=rt.ecf ECF Project Galileo Plan]<br />
<br />
[[ECF 2.1 Release Testing]]<br />
<br />
[[ECF 4.0 ToDo collection]]<br />
<br />
==New Stuff==<br />
<br />
[[Comments on the Riena Project Goals and Relationship to ECF project]]<br />
<br />
[[ECF Connection Creation and Management]]<br />
<br />
[[Extending Real-Time Shared Editing for Use with Other Editors]]<br />
<br />
[[Remote_Eclipse_RCP_Management | Remote Eclipse RCP Management]]<br />
<br />
[[DocShare Plugin|Real-Time Shared Editing]]<br />
<br />
[[Storage/Retrieval of IDs, IContainers using Equinox Secure Preferences]]<br />
<br />
[[Discovery of Remote Services]]<br />
<br />
[[Screen Captures over IM]]<br />
<br />
[[Integration with Mylyn]]<br />
<br />
[[Sharing Editor Selections]]<br />
<br />
[[ECF/REST_abstraction|REST abstraction (H. Staudacher)]]<br />
<br />
[[ECF/REST_ECF|REST abstraction (S. Gandhi)]]<br />
<br />
==ECF Adopters==<br />
<br />
[[ECF/Adopters|ECF Adopters List (please add yourself if you are using ECF)]]<br />
<br />
==Coding Conventions==<br />
<br />
ECF has decided to use the [http://www.eclipse.org/equinox/documents/coding.php Equinox Coding Conventions]. Also [http://www.eclipse.org/equinox/documents/coding.php on this page] are links to java<br />
source code formatter to use in Eclipse to easily enforce these conventions.<br />
<br />
==ECF at Eclipse Summit Europe 2006==<br />
[[Image:Eclipsesummiteurope2006.JPG|right|thumb|300px|From left to right: Roland Fru, Scott Lewis, and Mustafa Isik]]<br />
Check out these guys. They look happy to be working on Eclipse and ECF, no?<br />
<br />
Also see the [http://www.eclipsecon.org/summiteurope2006/index.php?page=detail/&id=35 ECF presentation] given at [http://www.eclipsecon.org/summiteurope2006 Eclipse Summit Europe 2006].<br />
<br />
<br />
==ECF at Eclipse Summit Europe 2008==<br />
<br />
[[ECF at Eclipse Summit Europe 2008 | Take a look at ECF on Eclipse Summit Europe 2008]]<br />
<br />
==ECF at EclipseCon 2009==<br />
[[Image:Eclipsecon2009_ecf_team.JPG|left|thumb|300px|From left to right: Scott Lewis, Mustafa Isik and Markus Kuppe]]<br />
ECF was busy at EclipseCon 2009, giving a number of talks and tutorials. The photo shows Scott, Mustafa and Markus wrapping up the conference at the Hyatt Bar, which is adjacent to the Santa Clara Convention Center.<br />
For those who couldn't make it, if the busyness during the conference is to serve as an indicator, you can expect a flurry of post-con blog posts and tweets to show up over the next week, giving you an idea of what EclipseCon 2009 was like.<br />
<br />
==Documentation==<br />
<br />
*[[ECF Documentation|Documentation: Intro Docs/Examples, Tutorials, Screencasts]]<br />
*[[ECF API Docs]]<br />
<br />
==Current Projects==<br />
<br />
===Components===<br />
*[[ECF Servers|Servers]]<br />
*[[DocShare Plugin | Cola/Realtime Shared Editing]]<br />
*[[Skype Provider|Skype Provider]]<br />
*[[VOIP|VOIP/Asterisk/Jingle/Call API]]<br />
*[[ECF Remote Services|Remote Services]]<br />
*[[ECF Bulletin Board Providers|Bulletin Board Providers]]<br />
<br />
===API===<br />
*[[ECF API Docs]]<br />
*[[Bot Framework]]<br />
*[[ECF Providers|Providers]]<br />
<br />
===Build===<br />
*[http://wiki.eclipse.org/images/b/b3/AutoBuild001.pdf ECF Build Part 1]<br />
*[http://wiki.eclipse.org/images/7/75/AutoBuild002.pdf ECF Build Part 2] (includes jar signing)<br />
*[http://wiki.eclipse.org/images/4/4a/IntegrationBuilds001.pdf Integration Builds]<br />
<br />
*[[How to VNC to ecf2]]<br />
*Automated Testing<br />
<br />
===Others===<br />
*[[Multi-User Sudoku]]<br />
*[[OLSR provider for ECF]]<br />
*[[Sharing objects over XMPP]]<br />
*[[ECF Apache Httpclient-Based Provider]]<br />
*[[JXTA provider for ECF]]<br />
<br />
{{ECF}}<br />
[[Category:Eclipse Communication Framework]]<br />
[[Category:Eclipse Technology Project]]</div>Codesurgeon.gmail.comhttps://wiki.eclipse.org/index.php?title=Eclipse_Communication_Framework_Project&diff=146868Eclipse Communication Framework Project2009-03-30T07:15:31Z<p>Codesurgeon.gmail.com: /* ECF at Eclipse Summit Europe 2008 */</p>
<hr />
<div>{{Infobox<br />
| name = Eclipse Communication Framework<br />
| download = http://www.eclipse.org/ecf/downloads.php<br />
| website = http://www.eclipse.org/ecf<br />
| list = ecf-dev<br />
| newsgroup = eclipse.technology.ecf<br />
| product = ECF<br />
| irc = eclipse-ecf<br />
| viewvc = org.eclipse.ecf/?root=RT_Project<br />
| psf = http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.ecf/releng/org.eclipse.ecf.releng/projectSet-anonymous.psf?root=RT_Project&view=co<br />
}}<br />
[http://www.eclipse.org/ecf/dev_resources.php ECF Developer Resources (CVS access, newsgroup/mailing list access, etc.)]<br/><br />
<br />
==ECF Conference Calls==<br />
<br />
ECF has weekly conference calls to discuss current and future issues on our roadmap. Anyone is welcome to join us.<br />
*International: 613-287-8000<br />
*Toll free: 866-362-7064<br />
*Participant passcode: 892048#<br />
<br />
===Next Conference Call: Thurs, Mar 19, 2008 1500 UTC NOTE: CANCELLED. WILL BE RESCHEDULED AFTER ECLIPSECON===<br />
<br />
[http://www.timeanddate.com/worldclock/fixedtime.html?year=2009&month=03&day=19&hour=15&min=00&sec=0 Mar 3, 2009, 8:00am pacific time/1500 UTC]<br />
<br />
[http://www.google.com/calendar/embed?src=q0gpojsaatmup0uilkklpe409c%40group.calendar.google.com&ctz=America/Los_Angeles Google Calendar]<br />
<br />
[[ECF Conference Call 3.19.2009|3.19.2009 Call Agenda/Notes]]<br />
<br />
*[[ECF Meeting Notes|Notes from Previous Meetings]]<br />
<br />
===Public and Private Chat Groups===<br />
ECF also has ongoing public and private chat groups. Please join us!<br />
<br />
*IRC (public): <b>irc.freenode.net</b> channel: <b>#eclipse-ecf</b> ECF URL <b>[irc://irc.freenode.net/#eclipse-ecf irc://<user>@irc.freenode.net/#eclipse-ecf]</b><br><br />
*XMPP (private): <b><user>@ecf.eclipse.org</b> multi-user chat: <b>ecf</b><br><br />
*ECF Generic (public): <b>ecftcp://ecf.eclipse.org:3282/server</b><br />
<br />
==Project Planning==<br />
<br />
[http://www.eclipse.org/projects/project-plan.php?projectid=rt.ecf ECF Project Galileo Plan]<br />
<br />
[[ECF 2.1 Release Testing]]<br />
<br />
[[ECF 4.0 ToDo collection]]<br />
<br />
==New Stuff==<br />
<br />
[[Comments on the Riena Project Goals and Relationship to ECF project]]<br />
<br />
[[ECF Connection Creation and Management]]<br />
<br />
[[Extending Real-Time Shared Editing for Use with Other Editors]]<br />
<br />
[[Remote_Eclipse_RCP_Management | Remote Eclipse RCP Management]]<br />
<br />
[[DocShare Plugin|Real-Time Shared Editing]]<br />
<br />
[[Storage/Retrieval of IDs, IContainers using Equinox Secure Preferences]]<br />
<br />
[[Discovery of Remote Services]]<br />
<br />
[[Screen Captures over IM]]<br />
<br />
[[Integration with Mylyn]]<br />
<br />
[[Sharing Editor Selections]]<br />
<br />
[[ECF/REST_abstraction|REST abstraction (H. Staudacher)]]<br />
<br />
[[ECF/REST_ECF|REST abstraction (S. Gandhi)]]<br />
<br />
==ECF Adopters==<br />
<br />
[[ECF/Adopters|ECF Adopters List (please add yourself if you are using ECF)]]<br />
<br />
==Coding Conventions==<br />
<br />
ECF has decided to use the [http://www.eclipse.org/equinox/documents/coding.php Equinox Coding Conventions]. Also [http://www.eclipse.org/equinox/documents/coding.php on this page] are links to java<br />
source code formatter to use in Eclipse to easily enforce these conventions.<br />
<br />
==ECF at Eclipse Summit Europe 2006==<br />
[[Image:Eclipsesummiteurope2006.JPG|right|thumb|300px|From left to right: Roland Fru, Scott Lewis, and Mustafa Isik]]<br />
Check out these guys. They look happy to be working on Eclipse and ECF, no?<br />
<br />
Also see the [http://www.eclipsecon.org/summiteurope2006/index.php?page=detail/&id=35 ECF presentation] given at [http://www.eclipsecon.org/summiteurope2006 Eclipse Summit Europe 2006].<br />
<br />
<br />
==ECF at Eclipse Summit Europe 2008==<br />
<br />
[[ECF at Eclipse Summit Europe 2008 | Take a look at ECF on Eclipse Summit Europe 2008]]<br />
<br />
==ECF at EclipseCon 2009==<br />
ECF was busy at EclipseCon 2009, giving a number of talks and tutorials. The photo shows Scott, Mustafa and Markus wrapping up the conference at the Hyatt Bar, which is adjacent to the Santa Clara Convention Center.<br />
[[Image:Eclipsecon2009_ecf_team.JPG|left|thumb|300px|From left to right: Scott Lewis, Mustafa Isik and Markus Kuppe]]<br />
For those who couldn't make it, if the busyness during the conference is to serve as an indicator, you can expect a flurry of post-con blog posts and tweets to show up over the next week, giving you an idea of what EclipseCon 2009 was like.<br />
<br />
==Documentation==<br />
<br />
*[[ECF Documentation|Documentation: Intro Docs/Examples, Tutorials, Screencasts]]<br />
*[[ECF API Docs]]<br />
<br />
==Current Projects==<br />
<br />
===Components===<br />
*[[ECF Servers|Servers]]<br />
*[[DocShare Plugin | Cola/Realtime Shared Editing]]<br />
*[[Skype Provider|Skype Provider]]<br />
*[[VOIP|VOIP/Asterisk/Jingle/Call API]]<br />
*[[ECF Remote Services|Remote Services]]<br />
*[[ECF Bulletin Board Providers|Bulletin Board Providers]]<br />
<br />
===API===<br />
*[[ECF API Docs]]<br />
*[[Bot Framework]]<br />
*[[ECF Providers|Providers]]<br />
<br />
===Build===<br />
*[http://wiki.eclipse.org/images/b/b3/AutoBuild001.pdf ECF Build Part 1]<br />
*[http://wiki.eclipse.org/images/7/75/AutoBuild002.pdf ECF Build Part 2] (includes jar signing)<br />
*[http://wiki.eclipse.org/images/4/4a/IntegrationBuilds001.pdf Integration Builds]<br />
<br />
*[[How to VNC to ecf2]]<br />
*Automated Testing<br />
<br />
===Others===<br />
*[[Multi-User Sudoku]]<br />
*[[OLSR provider for ECF]]<br />
*[[Sharing objects over XMPP]]<br />
*[[ECF Apache Httpclient-Based Provider]]<br />
*[[JXTA provider for ECF]]<br />
<br />
{{ECF}}<br />
[[Category:Eclipse Communication Framework]]<br />
[[Category:Eclipse Technology Project]]</div>Codesurgeon.gmail.comhttps://wiki.eclipse.org/index.php?title=File:Eclipsecon2009_ecf_team.JPG&diff=146867File:Eclipsecon2009 ecf team.JPG2009-03-30T07:05:43Z<p>Codesurgeon.gmail.com: uploaded a new version of "Image:Eclipsecon2009 ecf team.JPG": ECFers at EclipseCon 2009 - from left to right: Scott Lewis, Mustafa K. Isik and Markus Kuppe</p>
<hr />
<div>ECF at EclipseCon 2009 - from left to right: Scott Lewis, Mustafa K. Isik and Markus Kuppe</div>Codesurgeon.gmail.comhttps://wiki.eclipse.org/index.php?title=File:Eclipsecon2009_ecf_team.JPG&diff=146865File:Eclipsecon2009 ecf team.JPG2009-03-30T07:03:15Z<p>Codesurgeon.gmail.com: ECF at EclipseCon 2009 - from left to right: Scott Lewis, Mustafa K. Isik and Markus Kuppe</p>
<hr />
<div>ECF at EclipseCon 2009 - from left to right: Scott Lewis, Mustafa K. Isik and Markus Kuppe</div>Codesurgeon.gmail.comhttps://wiki.eclipse.org/index.php?title=Twitter&diff=138355Twitter2009-01-28T19:19:28Z<p>Codesurgeon.gmail.com: /* People */ put people first - added scott lewis and myself (ecf)</p>
<hr />
<div>[http://www.twitter.com Twitter] is a service for friends, family, and co–workers to communicate and stay connected through the exchange of quick, frequent answers to one simple question: What are you doing?<br />
<br />
The people listed below are part of the greater Eclipse community on Twitter.<br />
<br />
=== People ===<br />
<br />
* [http://twitter.com/njbartlett Neil Bartlett]<br />
* [http://twitter.com/caniszczyk Chris Aniszczyk]<br />
* [http://twitter.com/IanSkerrett Ian Skerrett]<br />
* [http://twitter.com/kohlerm Markus Kohler]<br />
* [http://twitter.com/martinlippert Martin Lippert]<br />
* [http://twitter.com/mik_kersten Mik Kersten]<br />
* [http://twitter.com/bokowski Boris Bokowski]<br />
* [http://twitter.com/jordibohmelopez Jordi Böhme López]<br />
* [http://twitter.com/darinrs Darin Swanson]<br />
* [http://twitter.com/euxx Eugene Kuleshov]<br />
* [http://twitter.com/codesurgeon Mustafa K. Isik]<br />
* [http://twitter.com/scottslewis Scott Lewis]<br />
* [http://twitter.com/EclipsePlanet PlanetEclipse]<br />
* [http://twitter.com/eclipsesource EclipseSource]<br />
* [http://twitter.com/m2eclipse Maven integration for Eclipse]<br />
<br />
=== Clients ===<br />
<br />
I highly recommend [http://www.tweetdeck.com TweetDeck] for your desktop, and [http://twitterfon.net/ TwitterFon] for your iPhone.<br />
<br />
[http://twitterfox.net/ TwitterFox] is a very nice Twitter client for FireFox.</div>Codesurgeon.gmail.comhttps://wiki.eclipse.org/index.php?title=EclipseDay_At_Googleplex&diff=107680EclipseDay At Googleplex2008-06-29T10:22:27Z<p>Codesurgeon.gmail.com: link to slides for Wiring Hacker Synapses: ... talk</p>
<hr />
<div>[[Image:Eclipse.JPG]]<br />
<br />
Eclipse Day at the Googleplex is a half day event for developers to learn about different Eclipse projects and related technologies. You are invited to attend and listen as experts from the Eclipse projects, Google and eBay share their experiences of using Eclipse. It's also a great opportunity for you to meet and network with other Eclipse enthusiasts. There is no cost to attend, but [http://wiki.eclipse.org/EclipseDay_At_Googleplex#Attendee_Registration pre-registration] is required.<br><br />
<br><br />
'''Registration is full''' as of June 3. We have also closed the waiting list as of June 16.<br />
<br><br><br />
<br />
'''Tuesday, June 24, 2008'''<br><br />
1:00pm - 7:30pm<br><br />
<br />
Googleplex<br><br />
Room: Grand Teton<br><br />
1501 Salado Road<br><br />
Mountain View, CA<br />
<br />
Thanks very much to the [http://code.google.com/opensource/ Google Open Source office] for hosting this event.<br />
<br />
<br />
__TOC__<br />
==Presentation Slides==<br />
[http://wiki.eclipse.org/images/8/82/AndroidsEclipseToolset.pdf Android Eclipse Toolset] - Xavier Ducrohet, Google<br><br />
[http://wiki.eclipse.org/images/f/f2/Eclipse-google-day2008-atf.zip Building Great RIA with ATF] - Philippe Ombredanne, nexB<br><br />
[http://wiki.eclipse.org/images/a/a2/EclipseAteBay.pdf Eclipse @ eBay] - Michael Galpin, eBay<br><br />
[http://dev.eclipse.org/viewcvs/index.cgi/pde-incubator/presentations/eclipseday/2008/ Plug-in Development Tips and Tricks] - Chris Aniszczyk, Code9<br><br />
[http://codesurgeonblog.com/2008/06/hot-off-press-slides-for-cola-tech-talk.html Wiring Hacker Synapses: Collaborative Coding and Team Tooling in Eclipse] - Scott Lewis, Mustafa K. Isik<br><br />
<br />
==Agenda==<br />
{| class="wikitable" border="1" cellpadding="2"<br />
! Time !! Track 1 - Ames Monument Room !! Track 2 - Grand Teton Room<br />
<br />
|-<br />
| 1:00-2:00 || colspan="2" align="center" | Main Tent Session: [http://wiki.eclipse.org/EclipseDay_At_Googleplex/Session_Abstacts#Eclipse_.40_eBay Eclipse @ eBay] - Michael Galpin, eBay<br />
<br />
|-<br />
| 2:00-2:50 || [http://wiki.eclipse.org/EclipseDay_At_Googleplex/Session_Abstacts#What.27s_New_in_CDT_Ganymede What's New in CDT Ganymede] - Sergey Prigogin, Google || [http://wiki.eclipse.org/EclipseDay_At_Googleplex/Session_Abstacts#How_Mylyn_Changes_the_Way_I_Develop How Mylyn Changes the Way I Develop] - Bjorn Freeman-Benson, Eclipse Foundation<br />
<br />
|-<br />
| 2:50-3:00 || colspan="2" align="center" | Break<br />
<br />
|-<br />
| 3:00-3:50 || [http://wiki.eclipse.org/EclipseDay_At_Googleplex/Session_Abstacts#Introduction_to_Equinox_and_OSGi Introduction to Equinox and OSGi] - Alex Alves, BEA Systems/Oracle || [http://wiki.eclipse.org/EclipseDay_At_Googleplex/Session_Abstacts#Tools_Make_the_Difference:_GWT_in_Eclipse Tools Make the Difference: GWT in Eclipse] - Bruce Johnson, Google<br />
<br />
|-<br />
| 3:50-4:10 || colspan="2" align="center" | Break<br />
<br />
|-<br />
| 4:10-5:00 || [http://wiki.eclipse.org/EclipseDay_At_Googleplex/Session_Abstacts#Building_Great_RIA_with_ATF Building Great RIA with ATF] - Philippe Ombredanne, nexB || [http://wiki.eclipse.org/EclipseDay_At_Googleplex/Session_Abstacts#Plug-in_Development_Tips_and_Tricks Plug-in Development Tips and Tricks] - Chris Aniszczyk, Code9<br />
<br />
|-<br />
| 5:10-6:00 || [http://wiki.eclipse.org/EclipseDay_At_Googleplex/Session_Abstacts#Android_Eclipse_Toolset Android Eclipse Toolset] - Xavier Ducrohet, Google || [http://wiki.eclipse.org/EclipseDay_At_Googleplex/Session_Abstacts#Wiring_Hacker_Synapses:_Collaborative_Coding_and_Team_Tooling_in_Eclipse Wiring Hacker Synapses: Collaborative Coding and Team Tooling in Eclipse] - Scott Lewis, Composent, [http://codesurgeonblog.com Mustafa K. Isik]<br />
<br />
<br />
|-<br />
| 6:00-7:30 || colspan="2" align="center" | Reception <br />
<br />
|-<br />
|}<br />
[[EclipseDay At Googleplex/Session Abstacts | All Session Abstracts]]<br />
<br />
==Attendee Registration==<br />
Registration and the waiting list are now full. Questions can be sent to Lynn at the e-mail address <lynn at eclipse dot org>.<br />
<br />
Name, Company:<br />
#Ian Skerrett, Eclipse Foundation<br />
#Robert Konigsberg, Google<br />
#Maksim Ustinov, Cisco Systems<br />
#Doug Chesney, LucidEra, Inc.<br />
#Tony Peppler, Ardent.com, Inc.<br />
#Dmitry Serebrennikov, Adchemy Inc.<br />
#Bradley Jones, Cloudshield Technologies<br />
#Jeff Miller, Google<br />
#Ivan Kelembetov, ameria GmbH<br />
#Kelly Campbell, Google <br />
#John Kline, Google<br />
#Terry Parker, Google<br />
#Sean Sullivan, Google<br />
#Brett Chabot, Google<br />
#Radim Kubacki, Google<br />
#Marius Milner, Google<br />
#Walfredo Cirne, Google<br />
#Bradley Hawkes, Google<br />
#Jeff Regan, Google<br />
#Wenbo Zhu, Google<br />
#Alex Le, Google<br />
#German Borbolla, Google<br />
#Benjamin Aranguren, HSTX<br />
#Richard Fetik, Data Confidential<br />
#Olaf Schneider, Cadence Design Systems<br />
#Mike Achenbach, Vendavo Inc.<br />
#Wes Isberg<br />
#John Schneider, Abaqus Inc.<br />
#Rob Glover<br />
#Vishnupriyan Venkatesan, Oracle<br />
#Kedar Mhaswade, Sun Microsystems Inc.<br />
#Kevin Nilson, Silicon Valley Google Technology User Group<br />
#Peter Zen<br />
#Ashvin Radiya, AvantSoft, Inc.<br />
#Vibha Dixit, AvantSoft, Inc.<br />
#Jay Deleanu, Synopsys Corporation<br />
#Rob Cameron, Juniper Networks<br />
#Meiji Wang, Juniper Networks<br />
#Ramana Anasuri, E*TRADE Financial<br />
#Pashupathi Kura, Savi Technology, Inc.<br />
#Doug Morgan, Google<br />
#Jayashree Beltur, E*TRADE Financial<br />
#Anil Chellani, E*TRADE Financial<br />
#Maleka Sankaragal, E*TRADE Financial<br />
#Rob Helmer, CustomWeather, Inc.<br />
#Geoff Flint, CustomWeather, Inc.<br />
#Lynda Leung, CustomWeather, Inc.<br />
#Nandha Srinivasan, E*TRADE Financial<br />
#John Nguyen, E*TRADE Financial<br />
#Krishna Kumar, Cognizant<br />
#Ram Prasad, Cognizant<br />
#Norm Smith, E*TRADE Financial<br />
#Mahesh Kumar, E*TRADE Financial<br />
#Ran Tao, E*TRADE Financial<br />
#Sharada Bettadahally, E*TRADE Financial<br />
#Victor Huang, E*TRADE Financial<br />
#Sanjay Sharma, E*TRADE Financial<br />
#Vikram Kannan, E*TRADE Financial<br />
#Hariharan Vijayakumar, Cognizant<br />
#Mallikarjuna Rao Talari, E*TRADE Financial<br />
#Hozefa Shiyaji, E*TRADE Financial<br />
#[http://mea-bloga.blogspot.com Chris Aniszczyk], [http://www.code9.com Code9]<br />
#Manish Madhusoodan, E*TRADE Financial<br />
#Abinov Vishen, E*TRADE Financial<br />
#John Brinnand, eBay<br />
#Meizhen Huang, E*TRADE Financial<br />
#Tim Cook, Coherent Logix Inc.<br />
#Milivoje Cvjetinovic, The Thomas Kinkade Company<br />
#Gurbir Singh, Synopsys, Inc.<br />
#Ehud Kaldor, EMC²<br />
#Scott Jones, On-Site Manager Inc.<br />
#Joseph Dean, On-Site Manager Inc.<br />
#Raghu Srinivasan, Oracle Inc.<br />
#Michael Jonath, Software AG<br />
#Reshma Shetty, Software AG<br />
#Greg Kim, Netflix<br />
#[http://iacobus.blogspot.com James E. Ervin] Groovy Eclipse/Eclipse Monkey<br />
#Aniruddha Shevade, Software AG<br />
#Michelle Yen, Software AG<br />
#Andrea Plesnarski, Software AG<br />
#Lakshmi Gubbala, Software AG<br />
#Korin Yang, Software AG<br />
#Joseph Wofford, Rearden Commerce<br />
#Mayank Jaiswal, Audible Magic<br />
#Stan Chan, Rearden Commerce<br />
#Tom McGee, State of California, Air Resources Board<br />
#Kamlesh Sangani, Rearden Commerce<br />
#Hossein Akhlaghpour, Rearden Commerce<br />
#Harald Rudell, Filmsoft<br />
#Henry Luis, Echelon Corporation<br />
#Raul Bajales, Globant<br />
#Yufen Kuo, MontaVista Software<br />
#Thomas Wilsher, Rearden Commerce<br />
#German Viscuso, db4objects, Inc.<br />
#Tim Chiu, Symyx Technologies<br />
#Mel Chung<br />
#Charles Rand, CDC Software<br />
#Ketan Bhanushali, E*TRADE Financial<br />
#Ray Valdes, Gartner Inc.<br />
#Siamak (Ash) Ashrafi<br />
#Ken Aung, Rearden Commerce<br />
#Jeremy Osborne<br />
#Al Thompson<br />
#Rashmeet Singh, E*TRADE Financial<br />
#Newton Chan, Foothill College<br />
#Aarthi Mohan, eBay<br />
#Durga Gududuntla, eBay<br />
#Joep Rottinghuis, eBay<br />
#Yogesh Chobe, Coherent Logix Inc.<br />
#Mike Forster, Google<br />
#Luiz-Otavio Zorzella, Google<br />
#Tina Nguyen, Google<br />
#Kotturu Chakravarthy, Google<br />
#Park Kittipatkul, Google<br />
#Rob Clevenger, Google<br />
#Michael Galpin, eBay<br />
#Philippe Ombredanne, nexB<br />
#Sergey Prigogin, Google<br />
#Scott Lewis, Composent<br />
#[http://codesurgeonblog.com Mustafa K. Isik]<br />
#Alex Alves, BEA Systems/Oracle<br />
#Bruce Johnson, Google<br />
#Xavier Ducrohet, Google<br />
#Bjorn Freeman-Benson, Eclipse Foundation<br />
#Christian Kurzke, Motorola<br />
#Ben Lindahl, Google <br />
'''-FULL REGISTRATION-'''<br />
<br />
==Waiting List==<br />
#Wen Huang<br />
#Angel Dzhigarov, Google<br />
#Patrick Deloulay, QuikCycle, Inc.<br />
#Srdjan Pantic, 2Wire, Inc.<br />
#Ashish Makani, Purdue Grad Student<br />
#Vincent Chin<br />
#Nick Chalko, Google<br />
#Vicente Ordonez, Google<br />
#Alfredo Bencomo, Code TI, NASA Ames Research Center<br />
#Steve Bilan<br />
#Chris DiGiano, Google<br />
#Ashutosh Arora, Samavaya<br />
#Seth Jennings, AT&T West<br />
#Glenn Abernethy, AT&T West<br />
#Ed Murphy, ITI Associates<br />
#Shailesh Mangal, D Software Inc.<br />
#Colin Flournoy, IAR Systems Software, Inc.<br />
#C Lee<br />
'''-FULL WAITING LIST-'''</div>Codesurgeon.gmail.comhttps://wiki.eclipse.org/index.php?title=EclipseDay_At_Googleplex&diff=101109EclipseDay At Googleplex2008-05-29T18:53:25Z<p>Codesurgeon.gmail.com: /* Agenda */ link for my name</p>
<hr />
<div>[[Image:Eclipse.JPG]]<br />
<br />
Eclipse Day at the Googleplex is a half day event for developers to learn about different Eclipse projects and related technologies. You are invited to attend and listen as experts from the Eclipse projects, Google and eBay share their experiences of using Eclipse. It's also a great opportunity for you to meet and network with other Eclipse enthusiasts. There is no cost to attend, but [http://wiki.eclipse.org/EclipseDay_At_Googleplex#Attendee_Registration pre-registration] is required.<br />
<br><br><br />
<br />
'''Tuesday, June 24, 2008'''<br><br />
1:00pm - 7:30pm<br><br />
<br />
Googleplex<br><br />
1600 Amphitheatre Parkway<br><br />
Mountain View, CA<br />
<br />
Thanks very much to the [http://code.google.com/opensource/ Google Open Source office] for hosting this event.<br />
<br />
<br />
__TOC__<br />
==Agenda==<br />
{| class="wikitable" border="1" cellpadding="2"<br />
! Time !! Track 1 !! Track 2 <br />
<br />
|-<br />
| 1:00-2:00 || colspan="2" align="center" | Main Tent Session: [http://wiki.eclipse.org/EclipseDay_At_Googleplex/Session_Abstacts#Eclipse_.40_eBay Eclipse @ eBay] - Michael Galpin, eBay<br />
<br />
|-<br />
| 2:00-2:50 || Building great RIA with ATF - Philippe Ombredanne, nexB || [http://wiki.eclipse.org/EclipseDay_At_Googleplex/Session_Abstacts#What.27s_New_in_CDT_Ganymede What's New in CDT Ganymede] - Sergey Prigogin, Google<br />
<br />
|-<br />
| 2:50-3:00 || colspan="2" align="center" | Break<br />
<br />
|-<br />
| 3:00-3:50 || [http://wiki.eclipse.org/EclipseDay_At_Googleplex/Session_Abstacts#Plug-in_Development_101 Plug-in Development 101] - Chris Aniszczyk || [http://wiki.eclipse.org/EclipseDay_At_Googleplex/Session_Abstacts#Wiring_Hacker_Synapses:_Collaborative_Coding_and_Team_Tooling_in_Eclipse Wiring Hacker Synapses: Collaborative Coding and Team Tooling in Eclipse] - Scott Lewis, Composent, [http://codesurgeonblog.com Mustafa K. Isik]<br />
<br />
|-<br />
| 3:50-4:15 || colspan="2" align="center" | Break<br />
<br />
|-<br />
| 4:15-5:00 || [http://wiki.eclipse.org/EclipseDay_At_Googleplex/Session_Abstacts#Introduction_to_Equinox_and_OSGi Introduction to Equinox and OSGi] - Alex Alves, BEA Systems/Oracle || [http://wiki.eclipse.org/EclipseDay_At_Googleplex/Session_Abstacts#Tools_Make_the_Difference:_GWT_in_Eclipse Tools Make the Difference: GWT in Eclipse] - Bruce Johnson, Google<br />
<br />
|-<br />
| 5:00-5:50 || [http://wiki.eclipse.org/EclipseDay_At_Googleplex/Session_Abstacts#Android.27s_Eclipse_Toolset Android's Eclipse Toolset] - Xavier Ducrohet, Google || [http://wiki.eclipse.org/EclipseDay_At_Googleplex/Session_Abstacts#How_Mylyn_Changes_the_Way_I_Develop How Mylyn Changes the Way I Develop] - Bjorn Freeman-Benson, Eclipse Foundation<br />
<br />
|-<br />
| 5:50-6:00 || colspan="2" align="center" | Break<br />
<br />
|-<br />
| 6:00-7:30 || colspan="2" align="center" | Reception <br />
<br />
|-<br />
|}<br />
[[EclipseDay At Googleplex/Session Abstacts | All Session Abstracts]]<br />
<br />
==Attendee Registration==<br />
There is no cost to attend this event but all attendees must register ahead of time. Space is also limited so please register early. To register, please email your name, company (if applicable) and e-mail address to <lynn at eclipse dot org>, and your name will be added to the wiki.<br />
<br />
Name, Company:<br />
#Ian Skerrett, Eclipse Foundation<br />
#Robert Konigsberg, Google<br />
#Maksim Ustinov, Cisco Systems<br />
#Doug Chesney, LucidEra, Inc.<br />
#Tony Peppler, Ardent.com, Inc.<br />
#Dmitry Serebrennikov, Adchemy Inc.<br />
#Bradley Jones, Cloudshield Technologies<br />
#Jeff Miller, Google<br />
#Ivan Kelembetov, ameria GmbH<br />
#Kelly Campbell, Google <br />
#John Kline, Google<br />
#Philip Zeyliger, Google<br />
#Terry Parker, Google<br />
#Sean Sullivan, Google<br />
#Lee Schumacher, Google<br />
#Brett Chabot, Google<br />
#Radim Kubacki, Google<br />
#Marius Milner, Google<br />
#Walfredo Cirne, Google<br />
#Bradley Hawkes, Google<br />
#Jeff Regan, Google<br />
#Wenbo Zhu, Google<br />
#Alex Le, Google<br />
#German Borbolla, Google<br />
#Benjamin Aranguren, HSTX<br />
#Richard Fetik, Data Confidential<br />
#Olaf Schneider, Cadence Design Systems<br />
#Mike Achenbach, Vendavo Inc.<br />
#Wes Isberg<br />
#John Schneider, Abaqus Inc.<br />
#Rob Glover<br />
#Vishnupriyan Venkatesan, Oracle<br />
#Tilak Michael, Oracle<br />
#Kedar Mhaswade, Sun Microsystems Inc.<br />
#Kevin Nilson, Silicon Valley Google Technology User Group<br />
#Peter Zen<br />
#Ashvin Radiya, AvantSoft, Inc.<br />
#Vibha Dixit, AvantSoft, Inc.<br />
#Jay Deleanu, Synopsys Corporation<br />
#Rob Cameron, Juniper Networks<br />
#Meiji Wang, Juniper Networks<br />
#Ramana Anasuri, E*TRADE Financial<br />
#Pashupathi Kura, Savi Technology, Inc.<br />
#Doug Morgan, Google<br />
#Jayashree Beltur, E*TRADE Financial<br />
#Anil Chellani, E*TRADE Financial<br />
#Maleka Sankaragal, E*TRADE Financial<br />
#Rob Helmer, CustomWeather, Inc.<br />
#Geoff Flint, CustomWeather, Inc.<br />
#Lynda Leung, CustomWeather, Inc.<br />
#Nandha Srinivasan, E*TRADE Financial<br />
#John Nguyen, E*TRADE Financial<br />
#Krishna Kumar, Cognizant<br />
#Ram Prasad, Cognizant<br />
#Norm Smith, E*TRADE Financial<br />
#Mahesh Kumar, E*TRADE Financial<br />
#Ran Tao, E*TRADE Financial<br />
#Sharada Bettadahally, E*TRADE Financial<br />
#Victor Huang, E*TRADE Financial<br />
#Sanjay Sharma, E*TRADE Financial<br />
#Vikram Kannan, E*TRADE Financial<br />
#Hariharan Vijayakumar, Cognizant<br />
#Mallikarjuna Rao Talari, E*TRADE Financial<br />
#Hozefa Shiyaji, E*TRADE Financial<br />
#[http://mea-bloga.blogspot.com Chris Aniszczyk]<br />
#Manish Madhusoodan, E*TRADE Financial<br />
#Abinov Vishen, E*TRADE Financial<br />
#John Brinnand, eBay<br />
#Meizhen Huang, E*TRADE Financial<br />
#Tim Cook, Coherent Logix Inc.<br />
#Milivoje Cvjetinovic, The Thomas Kinkade Company<br />
#Gurbir Singh, Synopsys, Inc.<br />
#Ehud Kaldor, EMC²<br />
#Scott Jones, On-Site Manager Inc.<br />
#Joseph Dean, On-Site Manager Inc.<br />
#Raghu Srinivasan, Oracle Inc.<br />
#Michael Jonath, Software AG<br />
#Reshma Shetty, Software AG<br />
#Greg Kim, Netflix<br />
#[http://iacobus.blogspot.com James E. Ervin] Groovy Eclipse/Eclipse Monkey<br />
#Aniruddha Shevade, Software AG<br />
#Michelle Yen, Software AG<br />
#Andrea Plesnarski, Software AG<br />
#Lakshmi Gubbala, Software AG<br />
#Korin Yang, Software AG<br />
#Joseph Wofford, Rearden Commerce<br />
#Mayank Jaiswal, Audible Magic<br />
#Stan Chan, Rearden Commerce<br />
#Tom McGee, State of California, Air Resources Board<br />
#Kamlesh Sangani, Rearden Commerce<br />
#Hossein Akhlaghpour, Rearden Commerce</div>Codesurgeon.gmail.comhttps://wiki.eclipse.org/index.php?title=EclipseDay_At_Googleplex/Session_Abstacts&diff=101108EclipseDay At Googleplex/Session Abstacts2008-05-29T18:51:22Z<p>Codesurgeon.gmail.com: /* Wiring Hacker Synapses - Collaborative Coding & Team Tooling in Eclipse */ title fix</p>
<hr />
<div>=====Eclipse @ eBay=====<br />
'''Michael Galpin, eBay'''<br><br />
<br />
Eclipse is great for Java development. Eclipse is great for web development. Eclipse is great for Java web development. The list goes on, but as your business becomes bigger, more specialized and more demanding, chances are that you won't find exactly what you need on that list. So what do you turn to? Eclipse. See how eBay uses the Eclipse you know and love, but also builds on top of it to handle its unique challenges. <br />
<br />
''About Michael Galpin:''<br><br />
Michael Galpin is an architect at eBay. He has worked on various projects in the past including eBay Neighborhoods, the next generation of My eBay, as well as eBay's own web development framework, V4. He also is a frequent writer for IBM developerWorks, TheServerSide.com, and the Java Developer's Journal. He has been programming professionally for 10+ years and holds a degree in mathematics from the California Institute of Technology.<br />
<br><br><br />
<br />
=====What's New in CDT Ganymede=====<br />
'''Sergey Prigogin, Google'''<br><br />
<br />
CDT Ganymede (a.k.a. 5.0) will be released by the end of June. This tech talk will introduce new features in CDT 5.0 and the most important bugs fixed in this release.<br />
<br><br><br />
<br />
=====Wiring Hacker Synapses: Collaborative Coding and Team Tooling in Eclipse=====<br />
'''Scott Lewis, Composent'''<br><br />
'''[http://codesurgeonblog.com Mustafa K. Isik]'''<br><br />
ECF is a communication framework and an increasing set of integrated tools. ECF provides APIs useful for the development of <br />
Equinox-based servers, RCP applications, and Eclipse-based development tools. The provider architecture supports the use of existing communications services, such as Google Talk and UI integration with web-based services, and other Eclipse-based tools. For example, for the upcoming Ganymede release, ECF is working on real-time shared editing of source code to support distributed team use cases like code reviews and collaborative debugging.<br />
<br><br><br />
<br />
=====Introduction to Equinox and OSGi=====<br />
'''Alex Alves, BEA Systems/Oracle'''<br><br />
<br />
Equinox is the core runtime platform for Eclipse. It is also an implementation of the OSGi specification. This session will introduce the key concepts of OSGi and show how you can build server applications using Equinox components, including Spring-DM for assembly and configuration.<br />
<br />
''About Alexandre Alves''<br><br />
Alex Alves is a computer scientist at BEA Systems/Oracle. Alex has worked with technologies such as real-time, CORBA, JEE, Web Services and OSGi for the past decade. He is currently the Architect for WebLogic Event Server, a light-weight application-server specific for event processing.<br />
<br><br><br />
<br />
=====Tools Make the Difference: GWT in Eclipse=====<br />
'''Bruce Johnson, Google'''<br><br />
<br />
Building high-performance Ajax easily with Google Web Toolkit (GWT) in Eclipse has always been possible, but soon it will be downright easy. Bruce will present GWT's upcoming Eclipse plugin that helps novices get started and lets experts fly.<br />
<br><br><br />
<br />
=====Android's Eclipse Toolset=====<br />
'''Xavier Ducrohet, Google'''<br><br />
<br />
An important and often overlooked part of creating a development platform is to provide a good tool suite. Android comes with high-quality tools integrated with Eclipse. Xavier will present these tools and discuss some of the things that were discovered while creating them.<br />
<br><br><br />
<br />
=====How Mylyn Changes the Way I Develop=====<br />
'''Bjorn Freeman-Benson, Eclipse Foundation'''<br><br />
<br />
Mylyn is an Eclipse project that gives tasks first-class status in the developer workspace. In this presentation Bjorn will show how task focused programming simplifies his (developer) life. Mylyn makes it easier for him to maintain focus while switching between tasks and to collaborate on tasks with geographically and time-zone disparate developers. Fair warning though: once you've started using Mylyn, you never want to return to the old ways.<br />
<br />
''About Bjorn Freeman-Benson:''<br><br />
Bjorn is the Director for Committer Community at the Eclipse Foundation, a position that is tailor-made for someone with his keen interest and experience in building high-quality software with geographically distributed teams. He has dabbled in applications and user interfaces, but returns, like the swallows to San Juan Capistrano, to his three foci: hardware, software and process (embedded devices, programming languages and software engineering). Bjorn has worked for OTI, Amazon.com, Rational and Gemstone, along with a career as a university professor. He has an M.Sc. and a Ph.D. in Computer Science from the University of Washington, and is happy to talk at length about his passion for orienteering and/or his love of flying.<br />
<br><br><br />
<br />
=====Plug-in Development 101=====<br />
'''Chris Aniszczyk, Independent'''<br><br />
<br />
Plug-ins are everywhere in Eclipse so come learn about how to develop them! For the first half of the talk, I will discuss what a plug-in is and what tooling is provided around developing plug-ins. For the second half, I will discuss tips and tricks that can save you time in developing plug-ins and will also talk about some lesser known, but extremely useful, parts of PDE.<br />
<br><br><br />
<br />
''About Chris Aniszczyk:''<br><br />
<br />
Chris Aniszczyk is the technical lead for the Plug-in Development Environment ([http://www.eclipse.org/pde PDE]) project at Eclipse. Chris also commits on various other Eclipse projects, has the honor to represent the committers on the Eclipse Board of Directors and sits on the Eclipse Architecture Council. Chris's passions are [http://mea-bloga.blogspot.com blogging], software advocacy, tooling and anything Eclipse. He's always available to discuss open-source or Eclipse over a frosty beverage.</div>Codesurgeon.gmail.comhttps://wiki.eclipse.org/index.php?title=EclipseDay_At_Googleplex&diff=101106EclipseDay At Googleplex2008-05-29T18:50:42Z<p>Codesurgeon.gmail.com: /* Agenda */ title fix ECF</p>
<hr />
<div>[[Image:Eclipse.JPG]]<br />
<br />
Eclipse Day at the Googleplex is a half day event for developers to learn about different Eclipse projects and related technologies. You are invited to attend and listen as experts from the Eclipse projects, Google and eBay share their experiences of using Eclipse. It's also a great opportunity for you to meet and network with other Eclipse enthusiasts. There is no cost to attend, but [http://wiki.eclipse.org/EclipseDay_At_Googleplex#Attendee_Registration pre-registration] is required.<br />
<br><br><br />
<br />
'''Tuesday, June 24, 2008'''<br><br />
1:00pm - 7:30pm<br><br />
<br />
Googleplex<br><br />
1600 Amphitheatre Parkway<br><br />
Mountain View, CA<br />
<br />
Thanks very much to the [http://code.google.com/opensource/ Google Open Source office] for hosting this event.<br />
<br />
<br />
__TOC__<br />
==Agenda==<br />
{| class="wikitable" border="1" cellpadding="2"<br />
! Time !! Track 1 !! Track 2 <br />
<br />
|-<br />
| 1:00-2:00 || colspan="2" align="center" | Main Tent Session: [http://wiki.eclipse.org/EclipseDay_At_Googleplex/Session_Abstacts#Eclipse_.40_eBay Eclipse @ eBay] - Michael Galpin, eBay<br />
<br />
|-<br />
| 2:00-2:50 || Building great RIA with ATF - Philippe Ombredanne, nexB || [http://wiki.eclipse.org/EclipseDay_At_Googleplex/Session_Abstacts#What.27s_New_in_CDT_Ganymede What's New in CDT Ganymede] - Sergey Prigogin, Google<br />
<br />
|-<br />
| 2:50-3:00 || colspan="2" align="center" | Break<br />
<br />
|-<br />
| 3:00-3:50 || [http://wiki.eclipse.org/EclipseDay_At_Googleplex/Session_Abstacts#Plug-in_Development_101 Plug-in Development 101] - Chris Aniszczyk || [http://wiki.eclipse.org/EclipseDay_At_Googleplex/Session_Abstacts#Wiring_Hacker_Synapses:_Collaborative_Coding_and_Team_Tooling_in_Eclipse Wiring Hacker Synapses: Collaborative Coding and Team Tooling in Eclipse] - Scott Lewis, Composent, Mustafa K. Isik<br />
<br />
|-<br />
| 3:50-4:15 || colspan="2" align="center" | Break<br />
<br />
|-<br />
| 4:15-5:00 || [http://wiki.eclipse.org/EclipseDay_At_Googleplex/Session_Abstacts#Introduction_to_Equinox_and_OSGi Introduction to Equinox and OSGi] - Alex Alves, BEA Systems/Oracle || [http://wiki.eclipse.org/EclipseDay_At_Googleplex/Session_Abstacts#Tools_Make_the_Difference:_GWT_in_Eclipse Tools Make the Difference: GWT in Eclipse] - Bruce Johnson, Google<br />
<br />
|-<br />
| 5:00-5:50 || [http://wiki.eclipse.org/EclipseDay_At_Googleplex/Session_Abstacts#Android.27s_Eclipse_Toolset Android's Eclipse Toolset] - Xavier Ducrohet, Google || [http://wiki.eclipse.org/EclipseDay_At_Googleplex/Session_Abstacts#How_Mylyn_Changes_the_Way_I_Develop How Mylyn Changes the Way I Develop] - Bjorn Freeman-Benson, Eclipse Foundation<br />
<br />
|-<br />
| 5:50-6:00 || colspan="2" align="center" | Break<br />
<br />
|-<br />
| 6:00-7:30 || colspan="2" align="center" | Reception <br />
<br />
|-<br />
|}<br />
[[EclipseDay At Googleplex/Session Abstacts | All Session Abstracts]]<br />
<br />
==Attendee Registration==<br />
There is no cost to attend this event but all attendees must register ahead of time. Space is also limited so please register early. To register, please email your name, company (if applicable) and e-mail address to <lynn at eclipse dot org>, and your name will be added to the wiki.<br />
<br />
Name, Company:<br />
#Ian Skerrett, Eclipse Foundation<br />
#Robert Konigsberg, Google<br />
#Maksim Ustinov, Cisco Systems<br />
#Doug Chesney, LucidEra, Inc.<br />
#Tony Peppler, Ardent.com, Inc.<br />
#Dmitry Serebrennikov, Adchemy Inc.<br />
#Bradley Jones, Cloudshield Technologies<br />
#Jeff Miller, Google<br />
#Ivan Kelembetov, ameria GmbH<br />
#Kelly Campbell, Google <br />
#John Kline, Google<br />
#Philip Zeyliger, Google<br />
#Terry Parker, Google<br />
#Sean Sullivan, Google<br />
#Lee Schumacher, Google<br />
#Brett Chabot, Google<br />
#Radim Kubacki, Google<br />
#Marius Milner, Google<br />
#Walfredo Cirne, Google<br />
#Bradley Hawkes, Google<br />
#Jeff Regan, Google<br />
#Wenbo Zhu, Google<br />
#Alex Le, Google<br />
#German Borbolla, Google<br />
#Benjamin Aranguren, HSTX<br />
#Richard Fetik, Data Confidential<br />
#Olaf Schneider, Cadence Design Systems<br />
#Mike Achenbach, Vendavo Inc.<br />
#Wes Isberg<br />
#John Schneider, Abaqus Inc.<br />
#Rob Glover<br />
#Vishnupriyan Venkatesan, Oracle<br />
#Tilak Michael, Oracle<br />
#Kedar Mhaswade, Sun Microsystems Inc.<br />
#Kevin Nilson, Silicon Valley Google Technology User Group<br />
#Peter Zen<br />
#Ashvin Radiya, AvantSoft, Inc.<br />
#Vibha Dixit, AvantSoft, Inc.<br />
#Jay Deleanu, Synopsys Corporation<br />
#Rob Cameron, Juniper Networks<br />
#Meiji Wang, Juniper Networks<br />
#Ramana Anasuri, E*TRADE Financial<br />
#Pashupathi Kura, Savi Technology, Inc.<br />
#Doug Morgan, Google<br />
#Jayashree Beltur, E*TRADE Financial<br />
#Anil Chellani, E*TRADE Financial<br />
#Maleka Sankaragal, E*TRADE Financial<br />
#Rob Helmer, CustomWeather, Inc.<br />
#Geoff Flint, CustomWeather, Inc.<br />
#Lynda Leung, CustomWeather, Inc.<br />
#Nandha Srinivasan, E*TRADE Financial<br />
#John Nguyen, E*TRADE Financial<br />
#Krishna Kumar, Cognizant<br />
#Ram Prasad, Cognizant<br />
#Norm Smith, E*TRADE Financial<br />
#Mahesh Kumar, E*TRADE Financial<br />
#Ran Tao, E*TRADE Financial<br />
#Sharada Bettadahally, E*TRADE Financial<br />
#Victor Huang, E*TRADE Financial<br />
#Sanjay Sharma, E*TRADE Financial<br />
#Vikram Kannan, E*TRADE Financial<br />
#Hariharan Vijayakumar, Cognizant<br />
#Mallikarjuna Rao Talari, E*TRADE Financial<br />
#Hozefa Shiyaji, E*TRADE Financial<br />
#[http://mea-bloga.blogspot.com Chris Aniszczyk]<br />
#Manish Madhusoodan, E*TRADE Financial<br />
#Abinov Vishen, E*TRADE Financial<br />
#John Brinnand, eBay<br />
#Meizhen Huang, E*TRADE Financial<br />
#Tim Cook, Coherent Logix Inc.<br />
#Milivoje Cvjetinovic, The Thomas Kinkade Company<br />
#Gurbir Singh, Synopsys, Inc.<br />
#Ehud Kaldor, EMC²<br />
#Scott Jones, On-Site Manager Inc.<br />
#Joseph Dean, On-Site Manager Inc.<br />
#Raghu Srinivasan, Oracle Inc.<br />
#Michael Jonath, Software AG<br />
#Reshma Shetty, Software AG<br />
#Greg Kim, Netflix<br />
#[http://iacobus.blogspot.com James E. Ervin] Groovy Eclipse/Eclipse Monkey<br />
#Aniruddha Shevade, Software AG<br />
#Michelle Yen, Software AG<br />
#Andrea Plesnarski, Software AG<br />
#Lakshmi Gubbala, Software AG<br />
#Korin Yang, Software AG<br />
#Joseph Wofford, Rearden Commerce<br />
#Mayank Jaiswal, Audible Magic<br />
#Stan Chan, Rearden Commerce<br />
#Tom McGee, State of California, Air Resources Board<br />
#Kamlesh Sangani, Rearden Commerce<br />
#Hossein Akhlaghpour, Rearden Commerce</div>Codesurgeon.gmail.comhttps://wiki.eclipse.org/index.php?title=EclipseDay_At_Googleplex&diff=101104EclipseDay At Googleplex2008-05-29T18:45:55Z<p>Codesurgeon.gmail.com: /* Agenda */ ECF talk title change</p>
<hr />
<div>[[Image:Eclipse.JPG]]<br />
<br />
Eclipse Day at the Googleplex is a half day event for developers to learn about different Eclipse projects and related technologies. You are invited to attend and listen as experts from the Eclipse projects, Google and eBay share their experiences of using Eclipse. It's also a great opportunity for you to meet and network with other Eclipse enthusiasts. There is no cost to attend, but [http://wiki.eclipse.org/EclipseDay_At_Googleplex#Attendee_Registration pre-registration] is required.<br />
<br><br><br />
<br />
'''Tuesday, June 24, 2008'''<br><br />
1:00pm - 7:30pm<br><br />
<br />
Googleplex<br><br />
1600 Amphitheatre Parkway<br><br />
Mountain View, CA<br />
<br />
Thanks very much to the [http://code.google.com/opensource/ Google Open Source office] for hosting this event.<br />
<br />
<br />
__TOC__<br />
==Agenda==<br />
{| class="wikitable" border="1" cellpadding="2"<br />
! Time !! Track 1 !! Track 2 <br />
<br />
|-<br />
| 1:00-2:00 || colspan="2" align="center" | Main Tent Session: [http://wiki.eclipse.org/EclipseDay_At_Googleplex/Session_Abstacts#Eclipse_.40_eBay Eclipse @ eBay] - Michael Galpin, eBay<br />
<br />
|-<br />
| 2:00-2:50 || Building great RIA with ATF - Philippe Ombredanne, nexB || [http://wiki.eclipse.org/EclipseDay_At_Googleplex/Session_Abstacts#What.27s_New_in_CDT_Ganymede What's New in CDT Ganymede] - Sergey Prigogin, Google<br />
<br />
|-<br />
| 2:50-3:00 || colspan="2" align="center" | Break<br />
<br />
|-<br />
| 3:00-3:50 || [http://wiki.eclipse.org/EclipseDay_At_Googleplex/Session_Abstacts#Plug-in_Development_101 Plug-in Development 101] - Chris Aniszczyk || [http://wiki.eclipse.org/EclipseDay_At_Googleplex/Session_Abstacts#Eclipse_Communication_Framework_for_Team_Tooling Wiring Hacker Synapses - Collaborative Coding & Team Tooling in Eclipse] - Scott Lewis, Composent, Mustafa K. Isik<br />
<br />
|-<br />
| 3:50-4:15 || colspan="2" align="center" | Break<br />
<br />
|-<br />
| 4:15-5:00 || [http://wiki.eclipse.org/EclipseDay_At_Googleplex/Session_Abstacts#Introduction_to_Equinox_and_OSGi Introduction to Equinox and OSGi] - Alex Alves, BEA Systems/Oracle || [http://wiki.eclipse.org/EclipseDay_At_Googleplex/Session_Abstacts#Tools_Make_the_Difference:_GWT_in_Eclipse Tools Make the Difference: GWT in Eclipse] - Bruce Johnson, Google<br />
<br />
|-<br />
| 5:00-5:50 || [http://wiki.eclipse.org/EclipseDay_At_Googleplex/Session_Abstacts#Android.27s_Eclipse_Toolset Android's Eclipse Toolset] - Xavier Ducrohet, Google || [http://wiki.eclipse.org/EclipseDay_At_Googleplex/Session_Abstacts#How_Mylyn_Changes_the_Way_I_Develop How Mylyn Changes the Way I Develop] - Bjorn Freeman-Benson, Eclipse Foundation<br />
<br />
|-<br />
| 5:50-6:00 || colspan="2" align="center" | Break<br />
<br />
|-<br />
| 6:00-7:30 || colspan="2" align="center" | Reception <br />
<br />
|-<br />
|}<br />
[[EclipseDay At Googleplex/Session Abstacts | All Session Abstracts]]<br />
<br />
==Attendee Registration==<br />
There is no cost to attend this event but all attendees must register ahead of time. Space is also limited so please register early. To register, please email your name, company (if applicable) and e-mail address to <lynn at eclipse dot org>, and your name will be added to the wiki.<br />
<br />
Name, Company:<br />
#Ian Skerrett, Eclipse Foundation<br />
#Robert Konigsberg, Google<br />
#Maksim Ustinov, Cisco Systems<br />
#Doug Chesney, LucidEra, Inc.<br />
#Tony Peppler, Ardent.com, Inc.<br />
#Dmitry Serebrennikov, Adchemy Inc.<br />
#Bradley Jones, Cloudshield Technologies<br />
#Jeff Miller, Google<br />
#Ivan Kelembetov, ameria GmbH<br />
#Kelly Campbell, Google <br />
#John Kline, Google<br />
#Philip Zeyliger, Google<br />
#Terry Parker, Google<br />
#Sean Sullivan, Google<br />
#Lee Schumacher, Google<br />
#Brett Chabot, Google<br />
#Radim Kubacki, Google<br />
#Marius Milner, Google<br />
#Walfredo Cirne, Google<br />
#Bradley Hawkes, Google<br />
#Jeff Regan, Google<br />
#Wenbo Zhu, Google<br />
#Alex Le, Google<br />
#German Borbolla, Google<br />
#Benjamin Aranguren, HSTX<br />
#Richard Fetik, Data Confidential<br />
#Olaf Schneider, Cadence Design Systems<br />
#Mike Achenbach, Vendavo Inc.<br />
#Wes Isberg<br />
#John Schneider, Abaqus Inc.<br />
#Rob Glover<br />
#Vishnupriyan Venkatesan, Oracle<br />
#Tilak Michael, Oracle<br />
#Kedar Mhaswade, Sun Microsystems Inc.<br />
#Kevin Nilson, Silicon Valley Google Technology User Group<br />
#Peter Zen<br />
#Ashvin Radiya, AvantSoft, Inc.<br />
#Vibha Dixit, AvantSoft, Inc.<br />
#Jay Deleanu, Synopsys Corporation<br />
#Rob Cameron, Juniper Networks<br />
#Meiji Wang, Juniper Networks<br />
#Ramana Anasuri, E*TRADE Financial<br />
#Pashupathi Kura, Savi Technology, Inc.<br />
#Doug Morgan, Google<br />
#Jayashree Beltur, E*TRADE Financial<br />
#Anil Chellani, E*TRADE Financial<br />
#Maleka Sankaragal, E*TRADE Financial<br />
#Rob Helmer, CustomWeather, Inc.<br />
#Geoff Flint, CustomWeather, Inc.<br />
#Lynda Leung, CustomWeather, Inc.<br />
#Nandha Srinivasan, E*TRADE Financial<br />
#John Nguyen, E*TRADE Financial<br />
#Krishna Kumar, Cognizant<br />
#Ram Prasad, Cognizant<br />
#Norm Smith, E*TRADE Financial<br />
#Mahesh Kumar, E*TRADE Financial<br />
#Ran Tao, E*TRADE Financial<br />
#Sharada Bettadahally, E*TRADE Financial<br />
#Victor Huang, E*TRADE Financial<br />
#Sanjay Sharma, E*TRADE Financial<br />
#Vikram Kannan, E*TRADE Financial<br />
#Hariharan Vijayakumar, Cognizant<br />
#Mallikarjuna Rao Talari, E*TRADE Financial<br />
#Hozefa Shiyaji, E*TRADE Financial<br />
#[http://mea-bloga.blogspot.com Chris Aniszczyk]<br />
#Manish Madhusoodan, E*TRADE Financial<br />
#Abinov Vishen, E*TRADE Financial<br />
#John Brinnand, eBay<br />
#Meizhen Huang, E*TRADE Financial<br />
#Tim Cook, Coherent Logix Inc.<br />
#Milivoje Cvjetinovic, The Thomas Kinkade Company<br />
#Gurbir Singh, Synopsys, Inc.<br />
#Ehud Kaldor, EMC²<br />
#Scott Jones, On-Site Manager Inc.<br />
#Joseph Dean, On-Site Manager Inc.<br />
#Raghu Srinivasan, Oracle Inc.<br />
#Michael Jonath, Software AG<br />
#Reshma Shetty, Software AG<br />
#Greg Kim, Netflix<br />
#[http://iacobus.blogspot.com James E. Ervin] Groovy Eclipse/Eclipse Monkey<br />
#Aniruddha Shevade, Software AG<br />
#Michelle Yen, Software AG<br />
#Andrea Plesnarski, Software AG<br />
#Lakshmi Gubbala, Software AG<br />
#Korin Yang, Software AG<br />
#Joseph Wofford, Rearden Commerce<br />
#Mayank Jaiswal, Audible Magic<br />
#Stan Chan, Rearden Commerce<br />
#Tom McGee, State of California, Air Resources Board<br />
#Kamlesh Sangani, Rearden Commerce<br />
#Hossein Akhlaghpour, Rearden Commerce</div>Codesurgeon.gmail.comhttps://wiki.eclipse.org/index.php?title=EclipseDay_At_Googleplex/Session_Abstacts&diff=101103EclipseDay At Googleplex/Session Abstacts2008-05-29T18:45:39Z<p>Codesurgeon.gmail.com: /* Eclipse Communication Framework for Team Tooling */ title change</p>
<hr />
<div>=====Eclipse @ eBay=====<br />
'''Michael Galpin, eBay'''<br><br />
<br />
Eclipse is great for Java development. Eclipse is great for web development. Eclipse is great for Java web development. The list goes on, but as your business becomes bigger, more specialized and more demanding, chances are that you won't find exactly what you need on that list. So what do you turn to? Eclipse. See how eBay uses the Eclipse you know and love, but also builds on top of it to handle its unique challenges. <br />
<br />
''About Michael Galpin:''<br><br />
Michael Galpin is an architect at eBay. He has worked on various projects in the past including eBay Neighborhoods, the next generation of My eBay, as well as eBay's own web development framework, V4. He also is a frequent writer for IBM developerWorks, TheServerSide.com, and the Java Developer's Journal. He has been programming professionally for 10+ years and holds a degree in mathematics from the California Institute of Technology.<br />
<br><br><br />
<br />
=====What's New in CDT Ganymede=====<br />
'''Sergey Prigogin, Google'''<br><br />
<br />
CDT Ganymede (a.k.a. 5.0) will be released by the end of June. This tech talk will introduce new features in CDT 5.0 and the most important bugs fixed in this release.<br />
<br><br><br />
<br />
=====Wiring Hacker Synapses - Collaborative Coding & Team Tooling in Eclipse=====<br />
'''Scott Lewis, Composent'''<br><br />
'''[http://codesurgeonblog.com Mustafa K. Isik]'''<br><br />
ECF is a communication framework and an increasing set of integrated tools. ECF provides APIs useful for the development of <br />
Equinox-based servers, RCP applications, and Eclipse-based development tools. The provider architecture supports the use of existing communications services, such as Google Talk and UI integration with web-based services, and other Eclipse-based tools. For example, for the upcoming Ganymede release, ECF is working on real-time shared editing of source code to support distributed team use cases like code reviews and collaborative debugging.<br />
<br><br><br />
<br />
=====Introduction to Equinox and OSGi=====<br />
'''Alex Alves, BEA Systems/Oracle'''<br><br />
<br />
Equinox is the core runtime platform for Eclipse. It is also an implementation of the OSGi specification. This session will introduce the key concepts of OSGi and show how you can build server applications using Equinox components, including Spring-DM for assembly and configuration.<br />
<br />
''About Alexandre Alves''<br><br />
Alex Alves is a computer scientist at BEA Systems/Oracle. Alex has worked with technologies such as real-time, CORBA, JEE, Web Services and OSGi for the past decade. He is currently the Architect for WebLogic Event Server, a light-weight application-server specific for event processing.<br />
<br><br><br />
<br />
=====Tools Make the Difference: GWT in Eclipse=====<br />
'''Bruce Johnson, Google'''<br><br />
<br />
Building high-performance Ajax easily with Google Web Toolkit (GWT) in Eclipse has always been possible, but soon it will be downright easy. Bruce will present GWT's upcoming Eclipse plugin that helps novices get started and lets experts fly.<br />
<br><br><br />
<br />
=====Android's Eclipse Toolset=====<br />
'''Xavier Ducrohet, Google'''<br><br />
<br />
An important and often overlooked part of creating a development platform is to provide a good tool suite. Android comes with high-quality tools integrated with Eclipse. Xavier will present these tools and discuss some of the things that were discovered while creating them.<br />
<br><br><br />
<br />
=====How Mylyn Changes the Way I Develop=====<br />
'''Bjorn Freeman-Benson, Eclipse Foundation'''<br><br />
<br />
Mylyn is an Eclipse project that gives tasks first-class status in the developer workspace. In this presentation Bjorn will show how task focused programming simplifies his (developer) life. Mylyn makes it easier for him to maintain focus while switching between tasks and to collaborate on tasks with geographically and time-zone disparate developers. Fair warning though: once you've started using Mylyn, you never want to return to the old ways.<br />
<br />
''About Bjorn Freeman-Benson:''<br><br />
Bjorn is the Director for Committer Community at the Eclipse Foundation, a position that is tailor-made for someone with his keen interest and experience in building high-quality software with geographically distributed teams. He has dabbled in applications and user interfaces, but returns, like the swallows to San Juan Capistrano, to his three foci: hardware, software and process (embedded devices, programming languages and software engineering). Bjorn has worked for OTI, Amazon.com, Rational and Gemstone, along with a career as a university professor. He has an M.Sc. and a Ph.D. in Computer Science from the University of Washington, and is happy to talk at length about his passion for orienteering and/or his love of flying.<br />
<br><br><br />
<br />
=====Plug-in Development 101=====<br />
'''Chris Aniszczyk, Independent'''<br><br />
<br />
Plug-ins are everywhere in Eclipse so come learn about how to develop them! For the first half of the talk, I will discuss what a plug-in is and what tooling is provided around developing plug-ins. For the second half, I will discuss tips and tricks that can save you time in developing plug-ins and will also talk about some lesser known, but extremely useful, parts of PDE.<br />
<br><br><br />
<br />
''About Chris Aniszczyk:''<br><br />
<br />
Chris Aniszczyk is the technical lead for the Plug-in Development Environment ([http://www.eclipse.org/pde PDE]) project at Eclipse. Chris also commits on various other Eclipse projects, has the honor to represent the committers on the Eclipse Board of Directors and sits on the Eclipse Architecture Council. Chris's passions are [http://mea-bloga.blogspot.com blogging], software advocacy, tooling and anything Eclipse. He's always available to discuss open-source or Eclipse over a frosty beverage.</div>Codesurgeon.gmail.comhttps://wiki.eclipse.org/index.php?title=EclipseDay_At_Googleplex&diff=99887EclipseDay At Googleplex2008-05-26T06:14:20Z<p>Codesurgeon.gmail.com: speaker addition to ECF talk</p>
<hr />
<div>[[Image:Eclipse.JPG]]<br />
<br />
Eclipse Day at the Googleplex is a half day event for developers to learn about different Eclipse projects and related technologies. You are invited to attend and listen as experts from the Eclipse projects, Google and eBay share their experiences of using Eclipse. It's also a great opportunity for you to meet and network with other Eclipse enthusiasts. There is no cost to attend, but [http://wiki.eclipse.org/EclipseDay_At_Googleplex#Attendee_Registration pre-registration] is required.<br />
<br><br><br />
<br />
'''Tuesday, June 24, 2008'''<br><br />
1:00pm - 7:30pm<br><br />
<br />
Googleplex<br><br />
1600 Amphitheatre Parkway<br><br />
Mountain View, CA<br />
<br />
Thanks very much to the [http://code.google.com/opensource/ Google Open Source office] for hosting this event.<br />
<br />
<br />
__TOC__<br />
==Agenda==<br />
{| class="wikitable" border="1" cellpadding="2"<br />
! Time !! Track 1 !! Track 2 <br />
<br />
|-<br />
| 1:00-2:00 || colspan="2" align="center" | Main Tent Session: [http://wiki.eclipse.org/EclipseDay_At_Googleplex/Session_Abstacts#Eclipse_.40_eBay Eclipse @ eBay] - Michael Galpin, eBay<br />
<br />
|-<br />
| 2:00-2:50 || Building great RIA with ATF - Philippe Ombredanne, nexB || [http://wiki.eclipse.org/EclipseDay_At_Googleplex/Session_Abstacts#What.27s_New_in_CDT_Ganymede What's New in CDT Ganymede] - Sergey Prigogin, Google<br />
<br />
|-<br />
| 2:50-3:00 || colspan="2" align="center" | Break<br />
<br />
|-<br />
| 3:00-3:50 || [http://wiki.eclipse.org/EclipseDay_At_Googleplex/Session_Abstacts#Plug-in_Development_101 Plug-in Development 101] - Chris Aniszczyk || [http://wiki.eclipse.org/EclipseDay_At_Googleplex/Session_Abstacts#Eclipse_Communication_Framework_for_Team_Tooling Eclipse Communication Framework for Team Tooling] - Scott Lewis, Composent, Mustafa K. Isik<br />
<br />
|-<br />
| 3:50-4:15 || colspan="2" align="center" | Break<br />
<br />
|-<br />
| 4:15-5:00 || [http://wiki.eclipse.org/EclipseDay_At_Googleplex/Session_Abstacts#Introduction_to_Equinox_and_OSGi Introduction to Equinox and OSGi] - Alex Alves, BEA Systems/Oracle || [http://wiki.eclipse.org/EclipseDay_At_Googleplex/Session_Abstacts#Tools_Make_the_Difference:_GWT_in_Eclipse Tools Make the Difference: GWT in Eclipse] - Bruce Johnson, Google<br />
<br />
|-<br />
| 5:00-5:50 || [http://wiki.eclipse.org/EclipseDay_At_Googleplex/Session_Abstacts#Android.27s_Eclipse_Toolset Android's Eclipse Toolset] - Xavier Ducrohet, Google || [http://wiki.eclipse.org/EclipseDay_At_Googleplex/Session_Abstacts#How_Mylyn_Changes_the_Way_I_Develop How Mylyn Changes the Way I Develop] - Bjorn Freeman-Benson, Eclipse Foundation<br />
<br />
|-<br />
| 5:50-6:00 || colspan="2" align="center" | Break<br />
<br />
|-<br />
| 6:00-7:30 || colspan="2" align="center" | Reception <br />
<br />
|-<br />
|}<br />
[[EclipseDay At Googleplex/Session Abstacts | All Session Abstracts]]<br />
<br />
==Attendee Registration==<br />
There is no cost to attend this event but all attendees must register ahead of time. Space is also limited so please register early. To register, please email your name, company (if applicable) and e-mail address to <lynn at eclipse dot org>, and your name will be added to the wiki.<br />
<br />
Name, Company:<br />
#Ian Skerrett, Eclipse Foundation<br />
#Robert Konigsberg, Google<br />
#Maksim Ustinov, Cisco Systems<br />
#Doug Chesney, LucidEra, Inc.<br />
#Tony Peppler, Ardent.com, Inc.<br />
#Dmitry Serebrennikov, Adchemy Inc.<br />
#Bradley Jones, Cloudshield Technologies<br />
#Jeff Miller, Google<br />
#Ivan Kelembetov, ameria GmbH<br />
#Kelly Campbell, Google <br />
#John Kline, Google<br />
#Philip Zeyliger, Google<br />
#Terry Parker, Google<br />
#Sean Sullivan, Google<br />
#Lee Schumacher, Google<br />
#Brett Chabot, Google<br />
#Radim Kubacki, Google<br />
#Marius Milner, Google<br />
#Walfredo Cirne, Google<br />
#Bradley Hawkes, Google<br />
#Jeff Regan, Google<br />
#Wenbo Zhu, Google<br />
#Alex Le, Google<br />
#German Borbolla, Google<br />
#Benjamin Aranguren, HSTX<br />
#Richard Fetik, Data Confidential<br />
#Olaf Schneider, Cadence Design Systems<br />
#Mike Achenbach, Vendavo Inc.<br />
#Wes Isberg<br />
#John Schneider, Abaqus Inc.<br />
#Rob Glover<br />
#Vishnupriyan Venkatesan, Oracle<br />
#Tilak Michael, Oracle<br />
#Kedar Mhaswade, Sun Microsystems Inc.<br />
#Kevin Nilson, Silicon Valley Google Technology User Group<br />
#Peter Zen<br />
#Ashvin Radiya, AvantSoft, Inc.<br />
#Vibha Dixit, AvantSoft, Inc.<br />
#Jay Deleanu, Synopsys Corporation<br />
#Rob Cameron, Juniper Networks<br />
#Meiji Wang, Juniper Networks<br />
#Ramana Anasuri, E*TRADE Financial<br />
#Pashupathi Kura, Savi Technology, Inc.<br />
#Doug Morgan, Google<br />
#Jayashree Beltur, E*TRADE Financial<br />
#Anil Chellani, E*TRADE Financial<br />
#Maleka Sankaragal, E*TRADE Financial<br />
#Rob Helmer, CustomWeather, Inc.<br />
#Geoff Flint, CustomWeather, Inc.<br />
#Lynda Leung, CustomWeather, Inc.<br />
#Nandha Srinivasan, E*TRADE Financial<br />
#John Nguyen, E*TRADE Financial<br />
#Krishna Kumar, Cognizant<br />
#Ram Prasad, Cognizant<br />
#Norm Smith, E*TRADE Financial<br />
#Mahesh Kumar, E*TRADE Financial<br />
#Ran Tao, E*TRADE Financial<br />
#Sharada Bettadahally, E*TRADE Financial<br />
#Victor Huang, E*TRADE Financial<br />
#Sanjay Sharma, E*TRADE Financial<br />
#Vikram Kannan, E*TRADE Financial<br />
#Hariharan Vijayakumar, Cognizant<br />
#Mallikarjuna Rao Talari, E*TRADE Financial<br />
#Hozefa Shiyaji, E*TRADE Financial<br />
#[http://mea-bloga.blogspot.com Chris Aniszczyk]<br />
#Manish Madhusoodan, E*TRADE Financial<br />
#Abinov Vishen, E*TRADE Financial</div>Codesurgeon.gmail.comhttps://wiki.eclipse.org/index.php?title=EclipseDay_At_Googleplex/Session_Abstacts&diff=99886EclipseDay At Googleplex/Session Abstacts2008-05-26T06:11:48Z<p>Codesurgeon.gmail.com: /* Eclipse Communication Framework for Team Tooling */ added myself (Mustafa) to the session abstract as I will be able to attend after all</p>
<hr />
<div>=====Eclipse @ eBay=====<br />
'''Michael Galpin, eBay'''<br><br />
<br />
Eclipse is great for Java development. Eclipse is great for web development. Eclipse is great for Java web development. The list goes on, but as your business becomes bigger, more specialized and more demanding, chances are that you won't find exactly what you need on that list. So what do you turn to? Eclipse. See how eBay uses the Eclipse you know and love, but also builds on top of it to handle its unique challenges. <br />
<br />
''About Michael Galpin:''<br><br />
Michael Galpin is an architect at eBay. He has worked on various projects in the past including eBay Neighborhoods, the next generation of My eBay, as well as eBay's own web development framework, V4. He also is a frequent writer for IBM developerWorks, TheServerSide.com, and the Java Developer's Journal. He has been programming professionally for 10+ years and holds a degree in mathematics from the California Institute of Technology.<br />
<br><br><br />
<br />
=====What's New in CDT Ganymede=====<br />
'''Sergey Prigogin, Google'''<br><br />
<br />
CDT Ganymede (a.k.a. 5.0) will be released by the end of June. This tech talk will introduce new features in CDT 5.0 and the most important bugs fixed in this release.<br />
<br><br><br />
<br />
=====Eclipse Communication Framework for Team Tooling=====<br />
'''Scott Lewis, Composent'''<br><br />
'''[http://codesurgeonblog.com Mustafa K. Isik]'''<br><br />
ECF is a communication framework and an increasing set of integrated tools. ECF provides APIs useful for the development of <br />
Equinox-based servers, RCP applications, and Eclipse-based development tools. The provider architecture supports the use of existing communications services, such as Google Talk and UI integration with web-based services, and other Eclipse-based tools. For example, for the upcoming Ganymede release, ECF is working on real-time shared editing of source code to support distributed team use cases like code reviews and collaborative debugging.<br />
<br><br><br />
<br />
=====Introduction to Equinox and OSGi=====<br />
'''Alex Alves, BEA Systems/Oracle'''<br><br />
<br />
Equinox is the core runtime platform for Eclipse. It is also an implementation of the OSGi specification. This session will introduce the key concepts of OSGi and show how you can build server applications using Equinox components, including Spring-DM for assembly and configuration.<br />
<br />
''About Alexandre Alves''<br><br />
Alex Alves is a computer scientist at BEA Systems/Oracle. Alex has worked with technologies such as real-time, CORBA, JEE, Web Services and OSGi for the past decade. He is currently the Architect for WebLogic Event Server, a light-weight application-server specific for event processing.<br />
<br><br><br />
<br />
=====Tools Make the Difference: GWT in Eclipse=====<br />
'''Bruce Johnson, Google'''<br><br />
<br />
Building high-performance Ajax easily with Google Web Toolkit (GWT) in Eclipse has always been possible, but soon it will be downright easy. Bruce will present GWT's upcoming Eclipse plugin that helps novices get started and lets experts fly.<br />
<br><br><br />
<br />
=====Android's Eclipse Toolset=====<br />
'''Xavier Ducrohet, Google'''<br><br />
<br />
An important and often overlooked part of creating a development platform is to provide a good tool suite. Android comes with high-quality tools integrated with Eclipse. Xavier will present these tools and discuss some of the things that were discovered while creating them.<br />
<br><br><br />
<br />
=====How Mylyn Changes the Way I Develop=====<br />
'''Bjorn Freeman-Benson, Eclipse Foundation'''<br><br />
<br />
Mylyn is an Eclipse project that gives tasks first-class status in the developer workspace. In this presentation Bjorn will show how task focused programming simplifies his (developer) life. Mylyn makes it easier for him to maintain focus while switching between tasks and to collaborate on tasks with geographically and time-zone disparate developers. Fair warning though: once you've started using Mylyn, you never want to return to the old ways.<br />
<br />
''About Bjorn Freeman-Benson:''<br><br />
Bjorn is the Director for Committer Community at the Eclipse Foundation, a position that is tailor-made for someone with his keen interest and experience in building high-quality software with geographically distributed teams. He has dabbled in applications and user interfaces, but returns, like the swallows to San Juan Capistrano, to his three foci: hardware, software and process (embedded devices, programming languages and software engineering). Bjorn has worked for OTI, Amazon.com, Rational and Gemstone, along with a career as a university professor. He has an M.Sc. and a Ph.D. in Computer Science from the University of Washington, and is happy to talk at length about his passion for orienteering and/or his love of flying.<br />
<br><br><br />
<br />
=====Plug-in Development 101=====<br />
'''Chris Aniszczyk, Independent'''<br><br />
<br />
Plug-ins are everywhere in Eclipse so come learn about how to develop them! For the first half of the talk, I will discuss what a plug-in is and what tooling is provided around developing plug-ins. For the second half, I will discuss tips and tricks that can save you time in developing plug-ins and will also talk about some lesser known, but extremely useful, parts of PDE.<br />
<br><br><br />
<br />
''About Chris Aniszczyk:''<br><br />
<br />
Chris Aniszczyk is the technical lead for the Plug-in Development Environment ([http://www.eclipse.org/pde PDE]) project at Eclipse. Chris also commits on various other Eclipse projects, has the honor to represent the committers on the Eclipse Board of Directors and sits on the Eclipse Architecture Council. Chris's passions are [http://mea-bloga.blogspot.com blogging], software advocacy, tooling and anything Eclipse. He's always available to discuss open-source or Eclipse over a frosty beverage.</div>Codesurgeon.gmail.comhttps://wiki.eclipse.org/index.php?title=EclipseDay_At_Googleplex&diff=94476EclipseDay At Googleplex2008-04-25T09:50:21Z<p>Codesurgeon.gmail.com: Philippe's last name was misspelled - corrected it</p>
<hr />
<div>'''Tuesday, June 24, 2008'''<br><br />
1:00pm - 7:30pm<br><br />
<br />
Googleplex<br><br />
1600 Amphitheatre Parkway<br><br />
Mountain View, CA<br />
<br />
<br />
__TOC__<br />
==Agenda==<br />
{| class="wikitable" border="1"<br />
! Time !! Track 1 !! Track 2 <br />
<br />
|-<br />
| 1:00-2:00 pm || colspan="2" align="center" | Main Tent Session <br />
<br />
|-<br />
| 2:00-2:50 pm || ATF - Philippe Ombredanne || CDT - Google Speaker<br />
<br />
|-<br />
| 2:50-3:00 pm || colspan="2" align="center" | Break<br />
<br />
|-<br />
| 3:00-3:50 pm || Plugin Development - Dan Rubel || ECF - Scott Lewis, Mustafa Isik<br />
<br />
|-<br />
| 3:50-4:15 pm || colspan="2" align="center" | Break<br />
<br />
|-<br />
| 4:15-5:00 pm || Equinox - Alexandre Alves || GWT - Google Speaker<br />
<br />
|-<br />
| 5:00-5:50 pm || Android - Google Speaker || Mylyn - Bjorn Freeman-Benson<br />
<br />
|-<br />
| 5:50-6:00 pm || colspan="2" align="center" | Break<br />
<br />
|-<br />
| 6:00-7:30pm || colspan="2" align="center" | Reception & BoF's<br />
<br />
|-<br />
|}<br />
<br />
==Attendees==<br />
#Name, Company</div>Codesurgeon.gmail.comhttps://wiki.eclipse.org/index.php?title=EclipseDay_At_Googleplex&diff=94475EclipseDay At Googleplex2008-04-25T09:48:37Z<p>Codesurgeon.gmail.com: added Alexandre Alves to the speakers list</p>
<hr />
<div>'''Tuesday, June 24, 2008'''<br><br />
1:00pm - 7:30pm<br><br />
<br />
Googleplex<br><br />
1600 Amphitheatre Parkway<br><br />
Mountain View, CA<br />
<br />
<br />
__TOC__<br />
==Agenda==<br />
{| class="wikitable" border="1"<br />
! Time !! Track 1 !! Track 2 <br />
<br />
|-<br />
| 1:00-2:00 pm || colspan="2" align="center" | Main Tent Session <br />
<br />
|-<br />
| 2:00-2:50 pm || ATF - Philippe Ombranne || CDT - Google Speaker<br />
<br />
|-<br />
| 2:50-3:00 pm || colspan="2" align="center" | Break<br />
<br />
|-<br />
| 3:00-3:50 pm || Plugin Development - Dan Rubel || ECF - Scott Lewis, Mustafa Isik<br />
<br />
|-<br />
| 3:50-4:15 pm || colspan="2" align="center" | Break<br />
<br />
|-<br />
| 4:15-5:00 pm || Equinox - Alexandre Alves || GWT - Google Speaker<br />
<br />
|-<br />
| 5:00-5:50 pm || Android - Google Speaker || Mylyn - Bjorn Freeman-Benson<br />
<br />
|-<br />
| 5:50-6:00 pm || colspan="2" align="center" | Break<br />
<br />
|-<br />
| 6:00-7:30pm || colspan="2" align="center" | Reception & BoF's<br />
<br />
|-<br />
|}<br />
<br />
==Attendees==<br />
#Name, Company</div>Codesurgeon.gmail.comhttps://wiki.eclipse.org/index.php?title=Google_Summer_of_Code_2008_Ideas&diff=91262Google Summer of Code 2008 Ideas2008-04-08T21:16:26Z<p>Codesurgeon.gmail.com: added myself as potential mentor - volunteering on two projects listed here</p>
<hr />
<div>== Rules ==<br />
* Be creative<br />
* Be specific: what do you want to be implemented<br />
* If you are willing to mentors those ideas, add your name and email to the idea.<br />
* It is ok to have a project idea without parent project<br />
* If you're an interested student, add your name and email next to the idea. It is ok to have several students interested by one idea.<br />
<br />
== Ideas ==<br />
<br />
{| border="1" cellpadding="2" width="100%"<br />
!width="20%"|Title<br />
!width="5%" align="center"|Project<br />
!width="40%"|Abstract - links to details/bugs/etc<br />
!width="10%"|Reporter<br />
!width="10%"|Possible mentor(s)<br />
!width="15%"|Comments<br />
!width="10%"|Potential student(s)<br />
|-<br />
| Support for user-defined refactorings in JDT<br />
| [http://www.eclipse.org/jdt JDT]<br />
| The idea is to produce a pattern language, rules engine, and user interface to allow the Java developer to perform queries n and make safe modifications of their code code. It's a superset of the current refactoring because ideally current refactorings could be expressed this new system, forming a nice set of initial examples. he users could then adapt those rules to their own purposes or come up with completely new ones. See {{bug|144642}} for more informations.<br />
| Ed Burnette<br />
| Martin Aeschlimann(?)<br />
| <br />
|<br />
|-<br />
| Continuous JUnit integration<br />
| [http://www.eclipse.org/jdt JDT]<br />
| Running a specific set of JUnit sets in the background while editing Java source code would help to detect defects early. The concept is to provide unobstrusive early detection and reporting of changes to source code that negatively affect its agreed upon functionality. Detecting failing tests would mark the changed source code with annotations to see which changes affected the green bar. There are already some (forgotten) bugs: {{bug|12167}} and {{bug|51292}}.<br />
| Benjamin Muskalla<br />
| [mailto:ContinuousJUnitGSoC08@lemmster.de Markus Kuppe] <br />
| [http://groups.csail.mit.edu/pag/continuoustesting/ PAG]<br />
| Sam Ryan, Victoria University Wellington New Zealand. Andrew Murray, Queen's University<br />
|-<br />
| toString generation<br />
| [http://www.eclipse.org/jdt JDT]<br />
| Like the setter/getter, equals and hashcode generator, it would be nice to have a little helper to generate toString methods. See bug {{bug|26070}} and take a look at [http://code.google.com/p/generate-tostring/wiki/Features this plugin] for some ideas. <br />
| Benjamin Muskalla<br />
| [mailto:toStringGSoC08@lemmster.de Markus Kuppe]<br />
| [http://eclipse-jutils.sourceforge.net/ JUtils]<br />
| Michelangelo De Simone, University of Salerno - Italy. Michael Diamond, Dartmouth College. Sam Ryan, Victoria University Wellington New Zealand. Andrew Murray, Queen's University. Filippo Bollini, Politecnico di Milano, Italy. [mailto:phenix789@gmail.com Claude Ramseyer] - Universite de Montpellier 2 - France, [mailto:ahmed.adan@gmail.com Ahmed Adan] - Carleton University<br />
|-<br />
| JDT and Google Code Search service <br />
| [http://www.eclipse.org/jdt JDT]<br />
| JDT and Google Code Search service integration: a)During debug under JDT source code are often unavailable. Google Code Search Source Provider should provide source code for corresponding class. b)Integrate common JDT search possibilities (for example "Search\References") with Google Code Search Service (Search not under local projects but in Web too).<br />
| Andrey Vakunov<br />
| <br />
|<br />
| Michelangelo De Simone, University of Salerno - Italy. Andrey Vakunov, Grodno State University<br />
|-<br />
| JDT Debugger Extensibility<br />
| [http://www.eclipse.org/eclipse/debug/jdt/ JDT Debug]<br />
| The JDT debugger provides debugging services and works with any JDPA-compliant JVM. The debugger has greatly matured over the years. Debugging facilities in general have not advanced much, however. Many in the research community would like to extend the capabilities of the JDT debugger without losing (or re-writing) existing functionality. Doing so often requires customizing how the JDT debugger makes use of the Java Debug Interface (JDI). This project would open up the JDI portion of the debugger in such a way that extensibility can be accomplished in a safe manner.<br />
| Jeffrey Czyz<br />
| <br />
| <br />
| Jeffrey Czyz, University at Buffalo<br />
|-<br />
| Implement a search mechanism for BPMN diagrams<br />
| [[STP/BPMN_Component|BPMN]]<br />
| Research indexing of domain specific models persisted in an XML format. Apply this research to indexing and searching BPMN diagrams.<br />
| Antoine Toulme<br />
| [mailto:antoine@lunar-ocean.com Antoine Toulme], [mailto:hmalphettes@intalio.com Hugues Malphettes]<br />
|<br />
|<br />
|-<br />
| Improve the usability of the BPMN editor<br />
| [[STP/BPMN_Component|BPMN]]<br />
| Gather feedback from users of the modeler. Select enhancements to support and develop them.<br />
| Antoine Toulme<br />
| [mailto:antoine@lunar-ocean.com Antoine Toulme], [mailto:hmalphettes@intalio.com Hugues Malphettes]<br />
|<br />
| [mailto:xiayehan@gmail.com Xia Yehan],Beijing University of Posts and Telecommunications,China<br />
|-<br />
| BPMN/BPEL to SCA model transformations for STP<br />
| [http://www.eclipse.org/stp/ STP]<br />
| This project will leverage and extend the existing STP Intermediate Model (STP-IM) in order to provide better support for transformations between process editors (BPMN and BPEL) and architecture editors (SCA in particular, potentially EID as well). The contribution would be of great importance to SOA developers and would therefore be an important incentive for the community adoption of the Eclipse STP. <br />
| Juan Cadavid<br />
| [mailto:adrian.mos@inria.fr Adrian Mos]<br />
|<br />
| Juan Cadavid, Universidad EAFIT, Medellín Colombia.<br />
|-<br />
| DITA or DocBook Help Content Producer<br />
| [http://www.eclipse.org/eclipse/platform-ua/main.html User Assistance]<br />
| Eclipse User Assistance allows for help content to be dynamically produced. Traditionally, all Eclipse content came in the form of hand-written HTML files. This is so 90's, we should have [http://help.eclipse.org/help32/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/extension-points/org_eclipse_help_contentProducer.html help content producers] to produce help content from DITA or DocBook files.<br />
| Chris Aniszczyk, Chris Goldthorpe(?)<br />
| [mailto:caniszczyk@gmail.com Chris Aniszczyk], [mailto:cgold@us.ibm.com Chris Goldthorpe], [mailto:d_a_carver@yahoo.com David Carver]<br />
| <br />
| Zhiyang Jiang,Chinese Academy of Sciences and [mailto:annieloww@gmail.com Annie Lo], Simon Fraser University (Canada)<br />
|-<br />
| GraphicsZilla<br />
| [http://www.eclipse.org/phoenix Phoenix]<br />
| Eclipse uses Bugzilla in many interesting ways. It uses it in the normal fashion for bug tracking. It also uses a modified version for IP tracking (IPZilla). This proposal is to create a GraphicsZilla to help streamline icon and graphics creation in Eclipse. This would allow not only programmers to contribute their talents to Eclipse. This would also make the process of where icons come from more transparent. See this [http://mea-bloga.blogspot.com/2007/01/graphicszilla-running-man.html blog post] and [https://bugs.eclipse.org/bugs/show_bug.cgi?id=170720 bug] for more info. Note, this would also provide a viewable repository of all the graphics used in Eclipse... which is currently lacking now.<br />
| Chris Aniszczyk<br />
| [mailto:caniszczyk@gmail.com Chris Aniszczyk]<br />
| <br />
| Goran Lochert, Faculty of Electrical Engineering and Computing<br />
|-<br />
| Bundles in a Browser<br />
| [http://www.eclipse.org/equinox Equinox]<br />
| Eclipse runs pretty much everywhere these days... in cell phones... devices... desktops... servers... how about a web browser? This proposal is being left open-ended for a purpose. I'd like to see a student figure out how to get Eclipse plug-ins (bundles) installed into a browser like Firefox and then somehow expose working with them via some API... maybe XPCOM or Javascript. That's all ;p<br />
| Chris Aniszczyk<br />
| [mailto:caniszczyk@gmail.com Chris Aniszczyk]<br />
| <br />
| Andrey Vakunov, Grodno State University<br />
|-<br />
| PDE fetch script factory for SVN<br />
| [http://www.eclipse.org/pde/ pde]<br />
| So far Eclipse only support CVS in a map file build. Though there exists an SVN impl, it's not EPL<br />
| Markus Kuppe<br />
| If nobody from PDE: [mailto:fetchGSoC08@lemmster.de Markus Kuppe]<br />
| [http://wiki.eclipse.org/index.php/PDEBuild#Building_from_a_subversion_repository SVN impl]<br />
|<br />
|-<br />
| PDE Ménage à trois: Scala and Java<br />
| [http://www.eclipse.org/pde PDE]<br />
| There are some crazy people out there developing Eclipse plug-ins using languages other than Java (how dare they ;p!). Scala is one of these popular languages and there already has been [http://neilbartlett.name/blog/2007/06/13/eclipse-pde-does-scala/ some Eclipse integration] to make this happen. However, PDE suffers from limitations that strictly binds itself to Java... the goal of this project would be to analyze these PDE limitations... and come up with patches or prototyped code to let PDE play better with Scala and other languages.<br />
| Chris Aniszczyk, Neil Bartlett (?)<br />
| [mailto:caniszczyk@gmail.com Chris Aniszczyk]<br />
| <br />
| Moises Osorio, Instituto Tecnologico de Culiacan, Culiacan Mexico. [mailto:wcoder.mx@gmail.com wcoder.mx@gmail.com]<br />
|-<br />
| Declarative Services (DS) Tooling<br />
| [http://www.eclipse.org/pde PDE]<br />
| Equinox finally has a stable implementation of the Declarative Services specification from OSGi. It's time to tool this beast. Any takers?<br />
| Chris Aniszczyk<br />
| [mailto:caniszczyk@gmail.com Chris Aniszczyk]<br />
| <br />
| Bartosz Michalik, Poznan University of Technology - Poland. Rafael Oliveira Nóbrega, Universidade Federal de Pernambuco - Brazil<br />
|-<br />
| PDE and JavaScript<br />
| [http://www.eclipse.org/pde PDE]<br />
| PDE allows you to create plug-ins using Java these days. This request is simply for a student to explore the realm of creating plug-ins using JavaScript or other languages. To start simple, I'd start with adding a new schema attribute of type "javascript" to allow plug-in authors to at least plug different languages in. From there, we can explore ideas on "how would you define a view" in such a way that you could take javascript or java code?<br />
| Chris Aniszczyk<br />
| Chris Aniszczyk<br />
| <br />
|<br />
|-<br />
| PDE and Equinox Transforms<br />
| [http://www.eclipse.org/pde PDE]<br />
| Equinox has a new component called transforms that allows you to transform various aspects of a plug-in during runtime. For example, a common use case is to write a transform that modifies some plugin.xml entries to not display certain menu items. This project aims to provide tooling for the transforms component so plugin authors can easily author transforms.<br />
| Chris Aniszczyk<br />
| Chris Aniszczyk<br />
| <br />
| Bartosz Michalik, Poznan University of Technology - Poland<br />
|-<br />
| XpandDoc documentation generator<br />
| [http://www.eclipse.org/modeling/m2t/?project=xpand#xpand M2T/Xpand]<br />
| Xpand is a template language which allows users to comment their templates with a JavaDoc-like syntax. So far, there is no tooling that can use this documentation. The goals of the project are to (1) create an engine that can parse Xpand template comments, (2) create a commandline tool that can generate a JavaDoc-like HTML output for all template comments in a project, and (3) enhance the Xpand text editor to show template comments in a tooltip when hovering over the respective template invocation.<br />
| Peter Friese<br />
| [mailto:peter.friese@itemis.de Peter Friese]<br />
| <br />
|<br />
|-<br />
| Refactorings for Xpand / Xtend / Check<br />
| [http://www.eclipse.org/modeling/m2t/?project=xpand#xpand M2T/Xpand]<br />
| Xpand, Xtend and Check are languages for writing code generators. As your code generator grows, you'll feel the desire to restructure your code generator templates. Currently, no refactoring support is available for Xpand / Xtend / Check. We're looking for a brave student willing to fill this void.<br />
| Peter Friese<br />
| [mailto:peter.friese@itemis.de Peter Friese]<br />
| <br />
|<br />
|-<br />
| Improving the TCP/IP Monitor Plugin <br />
| [http://www.eclipse.org/webtools/server/ WTP_Server_Tools]<br />
| The TCP/IP Monitor plugin available with the Eclipse WTP could use some improvement in several areas. A few suggestions are XML prettyfying, switchable layouts, persistable message logs, tabs for concurrent listeners, proxy mode, HTTP proxy support, simulation of slow connections, documentation and overall UI and usability improvement. IMHO, such additions, alongwith other requirements expressed by developers for this plugin, would make it more popular among the Eclipse Web developer community. <br />
| Suran Jayathilaka<br />
| <br />
| <br />
| Suran Jayathilaka, University Of Colombo School Of Computing - Sri lanka<br />
Saliya Ekanayake, Dept. of Computer Science & Engineering, University of Moratuwa. [mailto:esaliya@gmail.com esaliya@gmail.com]<br />
|-<br />
| Generic unit testing support<br />
| [http://www.eclipse.org/dltk DLTK]?<br />
| JUnit is well integrated at the moment used to test java code. As there are many other projects which need to implement other testing tools, we should be a generalized form of the Junit framework as provide some extension points to build the implementations of other XUnit frameworks on top of it. See {{bug|180884}} for more informations.<br />
| Benjamin Muskalla<br />
| <br />
| <br />
| <br />
|-<br />
| Web-CAT Eclipse plugin<br />
| [http://web-cat.cs.vt.edu/ Web-CAT]<br />
| Web-CAT is a plug-in-based web application that supports electronic submission and automated grading of programming assignments that is presently used by over 30 universities and colleges in the United States and elsewhere. The Web-CAT Grader supports traditional models of automated program grading, and also supports grading of assignments where students do their own testing. Web-CAT is already supported by an Eclipse plugin that allows students to view graders' comments on their assignments directly within the IDE. The aim of this project is to provide support for the graders as well, i.e., to allow professors, teaching assistants, and students to mark up code with comments, assign grades (both freeform and from rubrics), and so on. This will not only make grading easier, but will also help turn Eclipse into a student-friendly code review tool, which we hope will encourage wider use of code reviews in teaching.<br />
| Jason Montojo<br />
| [mailto:jmontojo@ca.ibm.com Jason Montojo], [mailto:gvwilson@cs.utoronto.ca Greg Wilson]<br />
| <br />
| Qi Yang, University of Toronto - Canada<br />
|-<br />
| Feature Diagram plugin<br />
| [https://stanley.cdf.toronto.edu/drproject/consulting-2008-01/featdiag Feature Diagram Prototype]<br />
| "Feature diagrams" are a graphical notation for describing the relationships between class elements that first appeared in Michael Feathers' book "[http://www.amazon.com/Working-Effectively-Legacy-Robert-Martin/dp/0131177052 Working Effectively with Legacy Code]". A prototype plugin for Eclipse that automatically produces feature diagrams, and allows users to modify their layout, now exists. The aim of this project is to connect that plugin to Eclipse's Java refactorings to allow drag-and-drop manipulation of the visual representations of fields and methods.<br />
| Greg Wilson<br />
| [mailto:gvwilson@cs.utoronto.ca Greg Wilson]<br />
| <br />
|<br />
|-<br />
| XQuery Syntax Editor<br />
| [http://www.eclipse.org/webtools/incubator XSL Tooling / Web Tools Incubator]<br />
| Provide basic support for XQuery syntax editing. Including coloring, validation, content assistance, possibly provide extensions for allowing the selection of which xquery editors can be used for validation. Preference pages for controling XQuery specificat options for generating output. Possible future ability to include debugging support.<br />
| David Carver<br />
| [mailto:d_a_carver@yahoo.com David Carver]<br />
| <br />
| Buddhika Laknath, University of Moratuwa - Sri Lanka. Filippo Bollini, Politecnico di Milano, Italy.<br />
|-<br />
| Eclipse single instance<br />
| [http://www.eclipse.org/platform platform]<br />
| More and more applications are eclipse RCP based applications. This is great but each application launch a JVM and load in memory quite often the same plug-ins. Like xul runner for mozilla, it would be interesting to have an "Eclipse runner". Issues to work on are how to manage several platforms (3.1, 3.2, 3.3, etc..) and share plug-ins (in memory). update : the problem seems to be adressed with p2 provided in eclipse 3.4 M6<br />
| Mariot Chauvin<br />
| Someone from platform project<br />
| <br />
|<br />
|-<br />
| BIRT JPA or JDO Connector<br />
| [http://www.eclipse.org/birt birt]<br />
| A data connector for BIRT Reports that allows BIRT to easily access data via JPA or JDO.<br />
| Markus Kuppe<br />
| The BIRT Project Team - Jason Weathersby<br />
| In [http://wiki.eclipse.org/Google_Summer_of_Code_2007_Ideas GSoC '07] the BIRT team was willing to mentor<br />
|<br />
|-<br />
| BIRT Reports and Connectors for Ad Revenue<br />
| [http://www.eclipse.org/birt birt]<br />
| This one is very business focused -- provide connectors and reports that allow Google customers and users to build their own reports on their Google Ad Revenue etc.<br />
| Kevin Peters<br />
| The BIRT Project Team - Jason Weathersby<br />
| In [http://wiki.eclipse.org/Google_Summer_of_Code_2007_Ideas GSoC '07] the BIRT team was willing to mentor<br />
| [mailto:kevjay@gmail.com Kevin Peters], University of Kansas<br />
|-<br />
| Barcode Support<br />
| [http://www.eclipse.org/birt birt]<br />
| See https://bugs.eclipse.org/bugs/show_bug.cgi?id=149928 for additional details.<br />
| Kevin Peters<br />
| The BIRT Project Team - Jason Weathersby<br />
| <br />
| [mailto:kevjay@gmail.com Kevin Peters], University of Kansas<br />
|-<br />
| JET Transforms/Wizards for creating project meta <br />
| [[Modeling Project Releng|Modeling Releng]]? [[Nexus_Project|Nexus]]?<br />
| Starting a new project requires a lot of duplicative code & metadata: .doc plugins/features, .examples plugins/features, .test examples/features, .sdk feature, .releng project. Being able to generate this from JET templates via a wizard would make it much easier to get a project up and running -- and then get a PDE build that much easier, too.<br />
| [[User:Nickb|Nick Boldt]] <br />
| [[User:Nickb|Nick Boldt]]<br />
| <br />
| Michael Robb, Mount Royal College, [mailto:zhaokeqiang@gmail.com, Ke Qiang Zhao], Tsinghua University<br />
|-<br />
| Rich text editing and wiki integration<br />
| [http://eclipse.org/mylyn Mylyn]<br />
| Provide wiki integration. This involves providing mechanisms for rich editing and viewing of task repository comments in wiki format, potentially adding wiki editing. see also [[Mylyn/Contribution_Ideas|More ideas for Mylyn projects]]<br />
| Steffen Pingel<br />
| Steffen Pingel<br />
| There are at least two projects already providing wiki editing in Eclipse, albeit without Mylyn integration: [http://www.matheclipse.org/en/Eclipse_Wikipedia_Editor Wikipedia Editor], [http://eclipsewiki.sourceforge.net/ Wiki Editor]. </[[User:nickb]]><br />
| [mailto:jingweno@cs.ubc.ca Jingwen 'Owen' Ou], The University of British Columbia, [http://www.cs.ubc.ca/~jingweno/soc/SoC2008.pdf Proposal] <br />
|-<br />
| Java based Abstract Syntax Tree (AST) generator for Ada Programs<br />
| [http://eclipse.org/hibachi Hibachi]<br />
| An Abstract Syntax Tree is the base framework for many powerful tools of a language IDE. For Hibachi, the Ada Development Toolkit project (like JDT or CDT), the presence of an AST would allow many more powerful IDE features, and improve those already in place (like refactoring, code folding, reformating).<br />
| Tom Grosman<br />
| Tom Grosman, Adam Haselhuhn<br />
| For a good idea about ASTs in Eclipse, see [http://www.eclipse.org/articles/article.php?file=Article-JavaCodeManipulation_AST/index.html JDT AST]<br />
| [mailto:zeroin23@gmail.com James Soh], Nanyang Technological University, Singapore<br />
[mailto:lipinski.bartosz@gmail.com Bartosz Lipinski], Warsaw Military University of Technology, Poland <br />
|-<br />
| Feature implementation for Ada Development Toolkit<br />
| [http://eclipse.org/hibachi Hibachi]<br />
| Implementation of new or extension of existing Hibachi funtionality. Depending on student interest and background, features may include but are not limited to code folding, Ada body generation, object tooltips display, dependency graphs and trees, code fixing, etc.<br />
| Tom Grosman<br />
| Tom Grosman, Adam Haselhuhn<br />
|<br />
| [mailto:zeroin23@gmail.com James Soh], Nanyang Technological University, Singapore <br />
|-<br />
| XML+CSS = IFigure<br />
| [http://www.eclipse.org/gef/ GEF/Draw2d]<br />
| Adding possibility to generate draw2d figures from XML and CSS descriptors (for example HTML subset and CSS). <br />
| Andrey Vakunov<br />
| [mailto:anthonyh_at_ca.ibm.com Anthony Hunter]<br />
| <br />
| Andrey Vakunov, Grodno State University<br />
|-<br />
| Equinox Console and script language integration<br />
| [http://www.eclipse.org/equinox/ Equinox]<br />
| Integrate any script language (Groovy or JRuby or Bash :-) ) in OSGi console. Add possibilities to write in OSGi console "s grep <my-service-name>"<br />
| Andrey Vakunov<br />
| <br />
| <br />
| Andrey Vakunov, Grodno State University<br />
|-<br />
| Buddy list for task assignments and CCs<br />
| [http://www.eclipse.org/mylyn/ Mylyn]<br />
| Enhance Mylyn's Rich Client Bugzilla to have an address book for CC's<br />
| Jingwen 'Owen' Ou<br />
| <br />
| Normally people work on projects with similar teammates and it would be nice to use previous queries to propose CCs. Details in [https://bugs.eclipse.org/bugs/show_bug.cgi?id=152415 bug 152415]<br />
| [mailto:jingweno@cs.ubc.ca Jingwen 'Owen' Ou], The University of British Columbia <br />
|-<br />
| Enhanced Eclipse search<br />
| [http://www.eclipse.org/platform platform]<br />
| Eclipse search plugin: provide an enhanced Eclipse search: better, faster, more relevant. Think Lucene or opengrok inside Eclipse.<br />
| Philippe Ombredanne<br />
| [mailto:philippe.ombredanne_at_eclipse.org Philippe Ombredanne]<br />
| <br />
| Jeffrey Czyz, University at Buffalo. Çağatay Çallı, Middle East Technical University - Turkey. Suran Jayathilaka, University Of Colombo School Of Computing - Sri lanka<br />
|-<br />
| Eclipse-Moodle integration<br />
| <br />
| The idea of this project is to provide an Eclipse plugin for the Moodle CMS e-learning system. This tool will enable students participating in online courses to import and export resources (projects or other materials) directly from an Eclipse workspace. Integration with Mylyn (for managing tasks assigned in such courses) could be an additional feature. <br />
| Aleksandra Woźniak<br />
| <br />
| <br />
| Aleksandra Woźniak, Poznan University of Technology & Adam Mickiewicz University - Poznan, Poland<br />
|-<br />
| Use case editor<br />
| [http://www.eclipse.org/proposals/ormf/ ORMF]?<br />
| Use case editor: for writing use cases in a textual form, managing sets of use cases and (maybe) generating UML diagrams as well as html and pdf files from them. <br />
| Aleksandra Woźniak<br />
| <br />
| <br />
| Aleksandra Woźniak, Poznan University of Technology & Adam Mickiewicz University - Poznan, Poland<br />
|-<br />
| Lazy development: generating functional tests from use cases, a proof of concept<br />
| [http://www.eclipse.org/proposals/ormf/ ORMF]<br />
| The availability of use case documents that are structured in nature opens up vast horizons of possibilities for automation of time consuming tasks. One of these is the generation of test scenarios and test cases for functional testing directly from the use case flows descriptions. This is a fantastic idea not only for its potential in the time it would save, but also (and especially) because the generated tests would be guaranteed to represent the functional requirements expressed in the use case. This project is a concrete exploration of this fascinating idea. You will take our current ideas on the subject and will find interesting ways to create test scenario matrices and, from these, individual test cases, with their associated data, conditions and verification points. The technologies that will be brought to bear include XML Schema, UML, BIRT, Eclipse SWT and JFace. <br />
| Barbara Rosi-Schwartz<br />
| [mailto:Barbara.Rosi-Schwartz@Etish.org Barbara Rosi-Schwartz], [mailto:Joel.Rosi-Schwartz@Etish.org Joel Rosi-Schwartz]<br />
| <br />
| <br />
|-<br />
| The use case puzzle complete: generating control artifacts from a use case mode<br />
| [http://www.eclipse.org/proposals/ormf/ ORMF]<br />
| We are personally using ORMF and Useme in our daily work and are drawing great pleasure from it, because it increases our productivity and it ensures that our use case model is valid and correct. However, whenever we want to see the big picture, either to get an overview of the requirements space or for management purposes, we find ourselves having to build by hand various types of control artifacts, such as use case lists, use case traceability matrices and dependency trees. Once created, these artifacts have to then be maintained up to date as the use case model evolves and changes. This task is tedious and time consuming at best and quite error prone at worst.This project is about the automatic and dynamic generation of such control artifacts from the use case model. You will extract the relevant information from the model stored in the database, create the appropriate reports and visualize them within Eclipse views. The lists and tables presented in these views will be customizable through sorting and filtering, to enable the user to extract all the information she requires at any given point in time. BIRT will be the tool of choice for this work.<br />
| Barbara Rosi-Schwartz<br />
| [mailto:Barbara.Rosi-Schwartz@Etish.org Barbara Rosi-Schwartz], [mailto:Joel.Rosi-Schwartz@Etish.org Joel Rosi-Schwartz]<br />
| <br />
| <br />
|-<br />
| Flow Visualisation: Generating activity diagrams from use cases<br />
| [http://www.eclipse.org/proposals/ormf/ ORMF]<br />
| ORMF provides structured use case definitions (documents) that are validated against an XML schema. One of the most desirable new features is to be able to dynamically generate UML Activity diagrams from the use case flows. The technologies that will be brought to bear include XML Schema, UML, Eclipse GMF and Eclipse EMF<br />
| Joel Rosi-Schwartz<br />
| [mailto:Barbara.Rosi-Schwartz@Etish.org Barbara Rosi-Schwartz], [mailto:Joel.Rosi-Schwartz@Etish.org Joel Rosi-Schwartz]<br />
| <br />
| <br />
|-<br />
| Filling up the corners: implementing the supportive document editor types<br />
| [http://www.eclipse.org/proposals/ormf/ ORMF]<br />
| There are number of "helper" document types that are core to the ORMF vision. I use the word "helper" because these types tend to be referred to by all other document types. The document types of interest are Glossary, Issues, NFR, Risks, and Assumptions. The students project would encompass creating the XML schema and structured editors for these types. The skills used would be XML Schema, Eclipse SWT and JFace, Eclipse GMF and Eclipse EMF. <br />
| Joel Rosi-Schwartz<br />
| [mailto:Barbara.Rosi-Schwartz@Etish.org Barbara Rosi-Schwartz], [mailto:Joel.Rosi-Schwartz@Etish.org Joel Rosi-Schwartz]<br />
| <br />
| <br />
|-<br />
| Augment p2 dependencies<br />
| [http://wiki.eclipse.org/Equinox_p2 p2]<br />
| In its first release, p2 limited its expression of dependencies to something equivalent to what most other package management system proposed (A package can say that it requires or conflicts with others). However several provisioning scenarios could benefit from more powerful inter-package dependencies (e.g, when mylyn and SVN are installed, install the connector). The goal of this project is to advance p2 by providing more powerful inter-package dependencies (and their mapping to the PB solver). Directions are: * more complex implications, * mapping filters into the solver, * expressing generic capabilities / dependencies (e.g. putting requirements on memory size, hard drive size, etc), * representing affinities between packages (see the OSGi notion of uses clauses) , * finding a way to automatically pick the most applicable line-up / recommendations<br />
| <br />
| [mailto:pascal_rapicault_at_ca.ibm.com Pascal Rapicault], Daniel Le Berre<br />
| <br />
|<br />
|-<br />
|Transformation from CIM to PIM<br />
| <br />
|This project aims to create a module for additional Omondo, allowing transformations from computation independent model (CIM) represented by activity diagram,to a platform independent model (PIM) represented by class diagram and use cases, based in model driven architecture (MDA) and UML. The project ([https://eclipsecon.greenmeetingsystems.com/submissions/view/609 paper]) was submitted to eclipsecon 2008.<br />
| Ernesto Suarez Lopez<br />
| <br />
| <br />
| [mailto:zhaokeqiang@gmail.com, Ke Qiang Zhao], Tsinghua University<br />
|-<br />
|Custom menu positioning for Eclipse Monkey scripts<br />
|[http://www.eclipse.org/dash/ Dash]<br />
|Eclipse Monkey scripts must currently reside under the Scripts menu, which doesn't integrate them well with existing functionality. When customizing a perspective, make it possible to add Monkey scripts to any menu (on the menu bar) that the user decides, both using specifiers in the script and through the UI.<br />
| [[User:Nitind|Nitin Dahyabhai]]<br />
| <br />
| <br />
|<br />
|-<br />
| Customizable display of objects in CDT debugger<br />
| [[CDT]]<br />
| Variables view of CDT debugger currently displays object variables as trees with each data member represented by a separate node. Some types, like std::string, have a complex internal structure, but a simple meaning. Having to open multiple levels of node hierarchy to see the contents of a string is very annoying. In most cases user does not care about all details of the string object and just wants to see the contents of the string. This problem can be solved by supporting user-defined auto expansion rules defining display formats for commonly used types. See {{bug|155331}} for more information.<br />
| Sergey Prigogin<br />
| [mailto:eclipse.sprigogin@gmail.com Sergey Prigogin]<br />
| <br />
|<br />
|-<br />
| CDT Windows Debugger<br />
| [[CDT]]<br />
| The CDT provides a front end to many debuggers in order to unify the debug UI around the Debug Platform augmented by a number of C/C++ specific debug views. We currently support the GNU debugger on Windows in parallel with build support for the GCC tool chain. We'd also like to support integration with the Windows SDK. We have Visual C++ build support. This project would be to add in Windows Debugger support.<br />
| Doug Schaefer<br />
| [mailto:doug.schaefer_at_windriver.com Doug Schaefer]<br />
| <br />
|<br />
|-<br />
| ECF and Yahoo<br />
| [http://www.eclipse.org/ecf/ ECF]<br />
| Implement a EPL'd version of the Yahoo messaging protocol and than code an ECF provider implementation for that. The baseline goal of this project is to just implement messanging for Yahoo... things like file transfer can come later or if there's time.<br />
| Chris Aniszczyk<br />
| [mailto:caniszczyk@gmail.com Chris Aniszczyk]<br />
| <br />
| Michael Berry, University of Kent, Canterbury, UK.<br />
|-<br />
| AIM Provider<br />
| [http://www.eclipse.org/ecf ECF]<br />
| ECF allows messaging protocols to be plugged in as providers. AIM isn't currently supported. The student can choose to implement the AIM (OSCAR) protocol themselves, or wrap an existing Java library like JOscar.<br />
| Chris Aniszczyk, Remy Suen<br />
| [mailto:caniszczyk@gmail.com Chris Aniszczyk], [mailto:remy.suen@gmail.com Remy Suen]<br />
| <br />
| Michael Berry, University of Kent, Canterbury, UK. Çağatay Çallı, Middle East Technical University - Turkey. Tharindu Mathew, University of Moratuwa Sri Lanka<br />
|-<br />
| IM for Eclipse<br />
| [http://www.eclipse.org/ecf ECF]<br />
| Developers work in project teams, and team members need to communicate. An IM program integrated into Eclipse itself will be useful for this, that's optimized to transfer large amounts of code which usual IM programs limit and also allows developers to be grouped accordingly.<br />
| Tharindu Mathew<br />
| [mailto:codesurgeon@gmail.com Mustafa K. Isik]<br />
| I think it's worth to take a look at the [http://www.eclipse.org/ecf ECF] project. Most of the features are already available there. This project might be re-targeted to provide for better UI integration of/exemplary apps for existing ECF functionality.<br />
| Michael Berry, University of Kent, Canterbury, UK. Michelangelo De Simone, University of Salerno - Italy. Michael Diamond, Dartmouth College. Sam Ryan, Victoria University Wellington New Zealand<br />
[mailto:rosema7@gmail.com Mei Ma], University of Melbourne, Australia, <br />
|-<br />
| Remote Service Deployment Tool<br />
| [http://www.eclipse.org/ecf ECF]<br />
| Take the R-OSGi Deployment Tool idea ([http://www.iks.inf.ethz.ch/publications/files/etx07.pdf paper]) and the prototype and port it to a new platform (PDE projects, ECF remote services, p2 for deployment) so that it can be easily used within Eclipse to deploy a distributed OSGi application. <br />
| Jan S. Rellermeyer<br />
| [mailto:rellermeyer_at_inf.ethz.ch Jan S. Rellermeyer]<br />
| <br />
|<br />
|-<br />
| VNC over ECF<br />
| [http://www.eclipse.org/ecf ECF]<br />
| Virtual Network Console is a popular screen sharing technology. It would be useful to have an implementation of VNC protocol for ECF. See [http://dev.eclipse.org/mhonarc/lists/ecf-dev/msg01452.html mailing list entry by Marek Zawirski] for a more detailed description of idea.<br />
| Scott Lewis<br />
| Scott Lewis, Remy Suen, Chris Aniszczyk, Markus Kuppe<br />
| <br />
|<br />
|-<br />
| Google Calendar access using ECF<br />
| [http://www.eclipse.org/ecf ECF]<br />
| [http://calendar.google.com Google Calendar] is a popular and open calendaring system. It would be useful to have an integrated ECF-based calendar for Eclipse. See [http://dev.eclipse.org/mhonarc/lists/ecf-dev/msg01452.html mailing list entry by Marek Zawirski] for a more detailed description of idea.<br />
| Scott Lewis<br />
| Scott Lewis, Remy Suen, Chris Aniszczyk, Markus Kuppe, [mailto:codesurgeon@gmail.com Mustafa K. Isik]<br />
| <br />
| Justin Jiao Yang Lin, University of Waterloo, Canada, and [mailto:qiang.gu.bupt@gmail.com, Gu Qiang], Beijing University of Posts and Telecommunications, China<br />
|-<br />
| SIP VoIP implementation for ECF<br />
| [http://www.eclipse.org/ecf ECF]<br />
| SIP is a popular signaling protocol, widely used for setting up VoIP calls with 2 or more participiants. This project aims to create working SIP/VoIP implementation, that will provide [http://wiki.eclipse.org/index.php/VOIP ECF Call API]. Implementation should allow VoIP calls using SIP from Eclipse and will make Eclipse a more functional softphone with an another protocol supported (already working implementations are jingle and Skype).<br />
| Marek Zawirski<br />
| Scott Lewis, Remy Suen, Chris Aniszczyk, Markus Kuppe?<br />
| <br />
| Marek Zawirski, Poznan University of Technology - Poland<br />
|-<br />
| Further ECF and Mylyn integration<br />
| [http://www.eclipse.org/ecf ECF]<br />
| Improvement of distributed development process is common goal of Mylyn and ECF projects. There have been [http://dev.eclipse.org/mhonarc/lists/ecf-dev/msg01195.html some efforts] of integrating these projects. However, there are still some fields where integration could be further extended. This especially covers contacting easily with other developers when doing issue-oriented development with Mylyn. Goal of this project is to extend integration between Mylyn and ECF to allow easy task-oriented communication or task exchange.<br />
| Marek Zawirski<br />
| Remy Suen, Scott Lewis, Chris Aniszczyk, Markus Kuppe?<br />
| <br />
|<br />
|-<br />
| Patch file editor with an outline view<br />
| [http://wiki.eclipse.org/index.php/WorkspaceTeam Workspace]<br />
| Juggling patches is the practice of every day work for all Eclipse developers. The goal of the project is to create a patch file editor with an outline view. The outline view would allow not only browsing the patch, but also navigating to included files, applying only selected hunks and so on.<br />
| Tomasz Zarna<br />
| [mailto:Tomasz.Zarna@pl.ibm.com Tomasz Zarna]<br />
| Details and initial code in {{bug|190418}}.<br />
|<br />
|-<br />
| "Compare With" dialog<br />
| [http://wiki.eclipse.org/index.php/WorkspaceTeam Workspace]<br />
| The goal of the project is to add a dialog allowing the user to select resources to compare. At this momement the user need to select 2 or 3 files with ctrl-clicking. This is not always as easy and reliable as it seems. The dialog would allow browsing the workspace or file system to locate the resource for comparison. Drag'n'dropping would be also very useful.<br />
| Tomasz Zarna<br />
| [mailto:Tomasz.Zarna@pl.ibm.com Tomasz Zarna]<br />
| See bug {{bug|224562}} for details.<br />
|<br />
|-<br />
| Patches comparison<br />
| [http://wiki.eclipse.org/index.php/WorkspaceTeam Workspace]<br />
| Juggling patches is the practice of every day work for all Eclipse developers. There are certain use cases when the user would like to compare two patches against each other. The problem is that straight comparison (two patches alone) is not enough, what we need here is comparing diffs in context.<br />
| Tomasz Zarna<br />
| [mailto:Tomasz.Zarna@pl.ibm.com Tomasz Zarna]<br />
| Details in {{bug|198149}} and {{bug|213043}}.<br />
|<br />
|-<br />
| diff from any comparison<br />
| [http://wiki.eclipse.org/index.php/WorkspaceTeam Workspace]<br />
| Generating a patch from any comparison is a very common request. It comes in many flavours: users would like to save a patch while comparing two files, two version in local history, current version and a one with a tag and so on. One thing they have in common is the ability to create a patch from actual comparison. It would be definietly a nice feature to have.<br />
| Tomasz Zarna<br />
| [mailto:Tomasz.Zarna@pl.ibm.com Tomasz Zarna]<br />
| Some of the bugs {{bug|71374}}, {{bug|103681}}, {{bug|151980}}...<br />
|<br />
|-<br />
| JavaScript debugger for IE<br />
| [http://eclipse.org/atf ATF]<br />
| ATF provides a Mozilla based debugger and an IE debugger would be welcomed. Some of the code from the [http://eclipse.org/actf ACTF] could be used as a base (an IE COM bridge)<br />
| Philippe Ombredanne<br />
| [mailto:pombredanne@gmail.com Philippe Ombredanne]<br />
| <br />
|<br />
|-<br />
| New Ajax tools and enhancements<br />
| [http://eclipse.org/atf ATF]<br />
| ATF needs your help to implement new features . See [http://www.eclipse.org/projects/slides/Continuation%20Review%20for%20the%20Eclipse%20ATF%20Project.pdf this documents for some ideas]<br />
| Philippe Ombredanne<br />
| [mailto:pombredanne@gmail.com Philippe Ombredanne]<br />
| <br />
|<br />
|-<br />
| Novel Rich Client<br />
| [http://www.eclipsemozilla.org EclipseMozilla.org] [http://eclipse.org/atf ATF]<br />
| Use the EclipseMozilla browser component and find new ways to program rich client applications. Especially, combining Eclipse technology with HTML and Flash is of interest. You should mesh Eclipse technology with web technologies to create a new unique way for rich client programming. This is a very innovative task. For more info contact me.<br />
| Thomas Derflinger<br />
| [mailto:tderflinger@gmail.com Thomas Derflinger]<br />
|<br />
| [mailto:miyamoto.takuya@lab.ime.cmc.osaka-u.ac.jp Takuya Miyamoto], Osaka University, Japan<br />
|-<br />
| Split File Editor<br />
| [http://www.eclipse.org/eclipse/platform-text/ Platform Text]<br />
| Implement a split file editor functionality: bug [https://bugs.eclipse.org/bugs/show_bug.cgi?id=8009 8009], the most voted-for bug ever in the entire Eclipse universe with >180 votes<br />
| Nikolay Botev<br />
| <br />
| <br />
| Nikolay Botev, San Jose State University - San Jose, California, USA.<br />
|-<br />
| Office-2007-ribbon-inspired UI<br />
| [http://www.eclipse.org/eclipse/platform-ui/ Platform UI]<br />
| Toolbars and Menus are so 20th century (extremely outdated) and un-user-friendly. Eclipse's menus are particularly overcrowded and hard to manage. This project would be a bold endeavour - a wild experiment in UI innovation. The idea is to replace the menu and toolbars with an Office 2007-ribbon-inspired structure. Here is a tentative design of the new UI. The structure consists of top-level tabs that correspond to Eclipse IDE perspectives. Under the current tab are groups of buttons with labels on the bottom (like Office 2007). The groups correspond to the current top-level menus. Labels display the full menu on click (unlike Office 2007). The buttons in each group represent a list of relevant actions determined based on some intelligent mix of most-frequently- and most-recently-used statistics. The structure has enough room for 3 rows of buttons in small format with small (16x16) icon and optional label to the right (like Office 2007). The most relevant buttons are displayed in large format when possible, filling all three rows, with a large icon and label below. The structure automatically expands and shrinks based on window size to take advantage of all available space on modern high-resolution/wide-screen displays (like Office 2007).<br />
| Nikolay Botev<br />
| <br />
| There has been a good start on this [http://www.hexapixel.com/ribbon/ here], and it might be EPL'd already.<br />
| Nikolay Botev, San Jose State University - San Jose, California, USA. [mailto:phenix789@gmail.com Claude Ramseyer] - Universite de Montpellier 2 - France<br />
|-<br />
| Equinox and SAT4J<br />
| [http://www.eclipse.org/equinox/ Equinox]<br />
| Do you like difficult problems of solving resolver problems at runtime? If so... this project is for you. The new provisioning work at Eclipse (p2) is using a new SAT Solver (SAT4J) to do complex resolver computations. This project will explore using SAT4J as the replacement for the current Equinox runtime resolver.<br />
| Chris Aniszczyk<br />
| [mailto:hargrave@us.ibm.com BJ Hargrave], [mailto:tjwatson@us.ibm.com Thomas Watson], [mailto:caniszczyk@gmail.com Chris Aniszczyk]<br />
| I think this should be more general. It should be about using constraint solver to replace the equinox resolver. Another open-source implementation of a solver is [http://choco-solver.net/index.php?title=Main_Page Choco]<br />
|<br />
|-<br />
| Support for StyledText<br />
| [http://www.eclipse.org/rap RAP]<br />
| One of the most asked features of RAP is the StyledText widget. Not only to show funny colored texts in your application but it's one of the most complex widgets to implement. But having at least some basic API working enabled RAP to port other parts of RCP to the web based on the new StyledText widget. More information about StyledText can be found [http://help.eclipse.org/stable/nftopic/org.eclipse.platform.doc.isv/reference/api/org/eclipse/swt/custom/StyledText.html here]. <br />
| Benjamin Muskalla<br />
| Frank Appel, Rüdiger Herrmann<br />
|<br />
| [mailto:phenix789@gmail.com Claude Ramseyer] - Universite de Montpellier 2 - France<br />
|-<br />
| Theme Editor<br />
| [http://www.eclipse.org/rap RAP]<br />
| Theming allows RAP application developers to give their applications a custom style. Currently, a theme must be defined as a .properties file. As the theming capabilities improve, these files are getting more and more complex. A theme editor should provide an easy-to-use user interface for defining themes. It could be shipped as part of the RAP tooling. For more information on the RAP theming, see the [http://help.eclipse.org/help33/index.jsp?topic=/org.eclipse.rap.help/help/html/advanced/theming.html online help].<br />
| Ralf Sternberg<br />
| [mailto:rsternberg@innoopract.com Ralf Sternberg]<br />
| <br />
| Mathias Schaeffner, Coventry University, UK<br />
|-<br />
| RAP product file<br />
| [http://www.eclipse.org/rap/ RAP]<br />
| At the moment RAP does not contain any public tool, which helps the developers to export their projects easier and faster. The goal is to write a plug-in which helps to export projects to a standalone application or a war file. <br />
| Balazs Brinkus<br />
| <br />
| <br />
| Balazs Brinkus, University of Szeged, Hungary<br />
|-<br />
| Ant buildfile refactorings<br />
| [http://www.eclipse.org/projects/project_summary.php?projectid=eclipse.platform.ant Platform Ant]<br />
| Ant buildfiles can become large and complex and would benefit from refactoring. Currently there is no support beyond renaming within a buildfile to allow the developer to efficiently refactor Ant buildfiles. The goals would be to implement an infrastructure to support refactorings in Ant buildfiles, participate in other components refactorings and provide a starter set of Ant buildfile refactorings. See {{bug|89938}} for some initial buildfile refactoring ideas.<br />
| Darin Swanson<br />
| [mailto:Darin_Swanson@us.ibm.com Darin Swanson]<br />
|<br />
|<br />
|-<br />
| Platform/Team Synchronization on top of RSE<br />
| [http://www.eclipse.org/dsdp/tm Target Management]<br />
| Remote System Explorer (RSE) provides transparent access to remote resources, including upload and download of files. Compare/merge of entire directory trees as well as minimal upload of trees thanks to Synchronization is currently a missing and often-asked-for feature. The goals would be integrating Platform/Team synchronization APIs on top of RSE file providers first, and then improving the algorithms for performing remote comparisons with minimal data transfer (by using timestamps, file sizes and MD5 hashes eventually). See {{bug|185925}} for more details.<br />
| Martin Oberhuber<br />
| [mailto:martin.oberhuber@windriver.com Martin Oberhuber]<br />
|<br />
| [mailto:miyamoto.takuya@lab.ime.cmc.osaka-u.ac.jp Takuya Miyamoto], Osaka University, Japan<br />
|-<br />
| BIRT-based Dash reports<br />
| [http://www.eclipse.org/dash Dash], [http://www.eclipse.org/birt BIRT]<br />
| Some ideas: provide Bugzilla stat reporting ({{bug|211163}}); provide newsgroup stat reporting ({{bug|211348}}); enhance [http://dash.eclipse.org/dash/commits/web-app/ existing queries] ({{bug|209711}}).<br />
| Nick Boldt<br />
| [[User:Nickb|Nick Boldt]]<br />
|<br />
|<br />
|-<br />
| All Markers View: Add "Filters" text field with query support<br />
| [http://www.eclipse.org/eclipse/platform-ui/ Platform UI]<br />
| Type Filters such in the Preferences dialog or Plugin Registry view are pretty cool Eclipse features: while typing only the things are shown matched by the query. This works fine filtering trees, but not applicable for tables. In a table or a table tree you may apply your filter only on a specific column or combine some simple queries. Such a filter input field should be added on top of the All Markers or Problems view allowing queries like: (a) Description:token - in Description column: a word which starts with token (b) Java AND (Eclipse OR Equinox) - in any column: Java and Eclipse or Java and Equinox (c) *Dialog< - in any column: a word ends with Dialog. A content assist should support entering complex queries by providing all columns titles plus ":". This proposal may simplify the filter dialog of the Problems view sometime.<br />
| [mailto:Holger.Voormann@verigy.com Holger Voormann], [mailto:loskutov@gmx.de Andrei Loskutov]<br />
| <br />
| <br />
| <br />
|-}<br />
<br />
More ideas can be found at [http://eclipse-wiki.info/GoogleSummerOfCode2007 Eclipse-Wiki], [[Mylyn Contribution Ideas|Mylyn Contribution Ideas page]], and [[Google Summer of Code 2007 Ideas|Google Summer of Code 2007 ideas]].<br />
<br />
== Unmatched Students ==<br />
Yifei Ma, Virginia Tech, Equinox</div>Codesurgeon.gmail.comhttps://wiki.eclipse.org/index.php?title=EclipseDay_At_Googleplex&diff=91257EclipseDay At Googleplex2008-04-08T20:54:09Z<p>Codesurgeon.gmail.com: moved ECF from Frameworks track to Tools track after ECF conference call - added myself as ECF speaker</p>
<hr />
<div>{| class="wikitable" border="1"<br />
! Topic !! Potential Speakers !! Responsible for Recruitment <br />
|-<br />
| <strong>Tools Track</strong><br />
<br />
|-<br />
| Plug-in Development || Eric Clayberg || Ian Skerrett <br />
<br />
|-<br />
| Ajax Toolkit Framework (ATF) || Phillippe Ombranne || Ian Skerrett<br />
<br />
|-<br />
| ECF || Scott Lewis, Mustafa Isik || Scott Lewis<br />
<br />
|-<br />
| CDT || ??? || ???<br />
<br />
|-<br />
| Mylyn || ??? || Ian Skerrett<br />
<br />
|-<br />
| Intro to PyDev || ??? || ???<br />
<br />
|-<br />
| p2 Deployment || ??? || Scott Lewis<br />
<br />
|-<br />
| Tips and Tricks Using JDT || ??? || ???<br />
<br />
|-<br />
| <strong>Frameworks</strong><br />
<br />
|-<br />
| GWT and Eclipse || ??? || ???<br />
<br />
<br />
|-<br />
| Testing (TPTP Profiling and Memory Analysis || ??? || Ian Skerrett<br />
<br />
|-<br />
| Developing for Android || ??? || ???<br />
<br />
|-<br />
| Equinox || ??? || Ian Skerrett<br />
<br />
<br />
|}</div>Codesurgeon.gmail.comhttps://wiki.eclipse.org/index.php?title=Bug_Reporting_FAQ&diff=57050Bug Reporting FAQ2007-10-26T00:27:04Z<p>Codesurgeon.gmail.com: linked to http://www.bugzilla.org/</p>
<hr />
<div>==Introduction==<br />
Eclipse bug reporting is done through a [http://www.bugzilla.org/ Bugzilla] server, a popular open source bug tracking system. This page will highlight a few cool features of Bugzilla that may not be immediately obvious and will answer questions about bug entry and searching. The gateway to the Eclipse bug database is: https://bugs.eclipse.org/bugs. It is also linked off of www.eclipse.org.<br />
<br />
==Bug Reporting References==<br />
* [http://www.bugzilla.org/docs/2.22/html/ The Bugzilla Guide] - The user manual for Bugzilla produced by the Bugzilla team.<br />
* [http://www.chiark.greenend.org.uk/%7Esgtatham/bugs.html How to Report Bugs Effectively] - Excellent tips on writing quality bug reports.<br />
* [https://bugs.eclipse.org/bugs/page.cgi?id=bug-writing.html Bug Writing Guidelines] - Bug writing guidelines from the Bugzilla team.<br />
<br />
==Cool Things in Bugzilla==<br />
===Bug Entry Templates===<br />
After filling in some or all of the fields on the new bug form (or the feature request form) you can press the “Remember values as bookmarkable template” button. Following the simple instructions on the resulting page will leave you with a bookmark that will take you to a new bug entry page with the fields filled in with the values you have specified. Hint: The template will include all the fields that you filled in so you may not want to enter Summary or Description text as part of your template.<br />
<br />
===Named, Saved and Bookmarked Queries===<br />
The main query page can be found at https://bugs.eclipse.org/bugs/query.cgi. Near the bottom of the query page you have options to:<br />
<br />
* Remember the current settings as the default for this page each time it is loaded.<br />
* Name the query for reuse later (each user has their own set of named queries).<br />
* Name the query for later reuseand add a link to the named query to your page footer for quick access. <br />
<br />
Use your user preferences link to manage named queries (https://bugs.eclipse.org/bugs/userprefs.cgi?bank=footer). Select a previously saved named query (this combo box only appears near the bottom of the query page if you have at least one named query saved)<br />
<br />
===Bug Counts===<br />
The “Reports” link on the footer of most Bugzilla pages takes you to a form that can summarize bug counts in interesting ways. The link is: https://bugs.eclipse.org/bugs/reports.cgi<br />
<br />
===Form Fill In===<br />
You may want to turn on the form fill in feature of Internet Explorer. This will provide drop down lists for picking values you have commonly entered into text fields in the various Bugzilla forms. This option can be found in the Internet Explorer menus Tools->Internet Options->Content->AutoComplete<br />
<br />
===Autolinkification===<br />
Bugzilla automatically creates hyperlinks for certain text patterns, see http://www.bugzilla.org/docs/tip/html/hintsandtips.html.<br />
Here are some examples of automatically created links: [https://bugs.eclipse.org/bugs/show_bug.cgi?id=2345 Bug 2345] has a [https://bugs.eclipse.org/bugs/show_bug.cgi?id=2345#c4 comment 4] (if linked from bug 2345), or [https://bugs.eclipse.org/bugs/show_bug.cgi?id=2345#c4 bug 2345 comment 4] (if linked from another bug).<br />
<br />
==Folders and Work Flow==<br />
===What is the life cycle of a bug report?===<br />
When a new bug is entered it begins life with a Status of either Unconfirmed for normal users or New for users with commit privileges. The bug is typically assigned to the component owner. The component owner will usually use a query of Status = Unconfirmed or New and Assigned to = me to browse what is essentially the component's inbox. She or he will assign bug reports to developers. Email will be generated to the developer (this part is configurable). (Note that the act of reassigning a bug to somebody changes its status to New). The developer may change unconfirmed bugs to new.<br />
<br />
The assigned developer will “accept” the bug which will change its status to Assigned. After working on the bug the developer will mark the bug as Resolved and will select a resolution (Fixed, Invalid, Wontfix, Worksforme).<br />
<br />
Once a bug is resolved there are still a few states it can transition too. How you choose to use these states will be up to individual teams. In our example, when a test pass comes up a component owner can build a query that searched for resolved bugs. After testing that the fix worked a resolved bug can be transitioned to verified, directly to closed, or in fact, reopened. By searching for bugs with a Status of verified and a resolution of fixed developers can come up with release notes. A verified/fixed bug can then be transitioned to closed. And yes, closed bugs can be reopened if need be. As an added bonus other bug status can be transitioned through verified to closed as well. This gives developers the opportunity to test worksforme claims.<br />
<br />
===How do I find a bug if all I know is the old RPRS PRID===<br />
RPRS is the problem tracking system used by the Eclipse team before we switched to Bugzilla. RPRS PRID's are 7 character ID's with a mix of numbers and letters (e.g. 1GETAYN). The RPRS PRID has been added to the end of each bug report summary (title) that was converted from the old system. So to find a bug report based on the PRID simply perform a search of the summary with the PRID. Searching is covered later on in this FAQ.<br />
<br />
===How can I get my enhancements in the committer's queue?===<br />
Please see 'Why do some bugs stay RESOLVED/LATER for years?'<br />
<br />
===Why do some bugs stay RESOLVED/LATER for years?===<br />
<br />
As quoted from [https://bugs.eclipse.org/bugs/show_bug.cgi?id=157642#c14 Bug 157642 Comment 14]:<br />
<br />
For most committers, there is an effectively unlimited supply of available bug<br />
reports and enhancement requests. How they choose what to work on is<br />
effectively a cost/benefit analysis. Cost in this case is the amount of work<br />
to address it, the work of ongoing maintenance for a new feature, the ripple<br />
cost a new feature may have on downstream projects, performance cost, etc. <br />
Things that increase the "benefit" side include benefits for end-users of<br />
Eclipse applications, benefits for downstream projects, etc. Also, input from<br />
the community in the form of votes, and input from the PMC and from committers<br />
on other projects increase the "benefit" side of the equation. A long-dormant<br />
bug may be reopened either because the cost has gone down (perhaps some<br />
underlying infrastructure is now available that makes the problem easier to<br />
solve), or the benefit has gone up (more requests from users, committers on<br />
other projects, the PMC, etc). If the cost/benefit ratio of a bug does not<br />
change, it may remain unaddressed forever.<br />
<br />
===Why is using RESOLVED/LATER bad?===<br />
Bugzilla provides a better way of handling this: you can leave the bug in the NEW<br />
state, but just update the 'target milestone' to be LATER (each project has its own milestones,<br />
so each project will need to add a target milestone of LATER to make this work). That way,<br />
the bug is still in an OPEN state (as opposed to a CLOSED state, as defined in the <br />
[https://bugs.eclipse.org/bugs/page.cgi?id=fields.html#status bugzilla statuses document])<br />
and as such, comes up in any search looking for open bugs. However, you've still got the<br />
ability to filter out the LATER milestones in your reports, if you want to.<br />
<br />
===Deprecated resolutions===<br />
The LATER and REMIND resolutions are obsolete. Please see [https://bugs.eclipse.org/bugs/show_bug.cgi?id=178923#c75 Bug 178923 Comment 75] for more information.<br />
<br />
<br />
==Bug Entry==<br />
===What is the difference between "Report a new bug" and “Enter a feature request”?===<br />
"Enter a feature request" provides a simplified form to enter information pertaining to a suggested enhancement. Certain fields are automatically saved with default values. When a feature request is entered it is stored in the regular bug database along with the bugs. Feature severities are automatically set to "Enhancement"<br />
<br />
===How are the values for Platform and OS filled in on the bug entry form?===<br />
These fields are set based on information provided automatically by your browser. In general they will reflect the Platform and OS you are using when you enter the bug. Please be sure to change these to accurately reflect the bug you are entering. Feature requests have Platform and OS set to “All”.<br />
<br />
===What is the difference between Severity and Priority?===<br />
Severity is assigned by a user and describes the level of impact the bug is having on them. Priority is assigned by the developer and describes the importance a developer places on fixing the bug. P1 is the highest priority, P5 is the lowest.<br />
==Searching==<br />
<br />
===How do I find a particular bug number?===<br />
There are several ways to do this:<br />
<br />
* Use the Quick Search box on: https://bugs.eclipse.org/bugs.<br />
* Type the bug number in the bug # action box on the footer of most Bugzilla pages.<br />
* Put the bug number in the “Only bugs numbered” field on the main query page at: https://bugs.eclipse.org/bugs/query.cgi<br />
<br />
===How do I search for bugs containing certain text?===<br />
There are several ways to do this:<br />
<br />
* Use the Quick Search box on: https://bugs.eclipse.org/bugs/. This box will only perform a case insensitive search on bug summaries. It will not search descriptions or comments.<br />
* Fill in the “Summary” and/or “A description entry:” fields on the main query page at: https://bugs.eclipse.org/bugs/query.cgi. The “description entry” field will search the initial description and all the comments of a bug report.<br />
<br />
Note that the bug # field in the footer of most Bugzilla pages can not be used to search for text.<br />
<br />
===Query Hints===<br />
The “Status”, “Resolution”, “Platform”, “OpSys”, “Priority” and “Severity” multi-select list boxes on the main query page (https://bugs.eclipse.org/bugs/query.cgi) only need to be set if you want to limit your query to certain values for these fields. If you want to search for bugs with any status no items in the “Status” list should be selected. It is not necessary to select all the items in the list.<br />
<br />
===What is the “My Bugs” link on the footer of most Bugzilla pages?===<br />
This is a predefined query for bugs that are New, Assigned or Reopened and that where reported by or assigned to you. You may not change this predefined query but you can remove the link from your footer using the “prefs” link on the footer.<br />
<br />
==Miscellaneous==<br />
===Why am I getting so much email and how can I make it stop===<br />
Go to the “Change password or user preferences” link off the main page (https://bugs.eclipse.org/bugs/userprefs.cgi) and select Email settings. Change your settings to suite your preferences.<br />
<br />
===What are Keywords===<br />
Key words are a set of defined words that can be associated with a bug report. Quick searches can be done on keywords. The following points should be kept in mind about keywords:<br />
<br />
* They are defined by the Bugzilla maintainer. Send requests for new key words to the Bugzilla maintainer.<br />
* They are case insensitive.<br />
* They can not be added to a bug report when it is first created. They can only be added when editing a bug report.<br />
* The keywords are described at: https://bugs.eclipse.org/bugs/describekeywords.cgi<br />
<br />
[[Category:FAQ]][[Category:How to Contribute]]</div>Codesurgeon.gmail.comhttps://wiki.eclipse.org/index.php?title=Bug_Reporting_FAQ&diff=57049Bug Reporting FAQ2007-10-26T00:21:54Z<p>Codesurgeon.gmail.com: removed indefinite article "an" before "bugzilla" - added interpunction and space</p>
<hr />
<div>==Introduction==<br />
Eclipse bug reporting is done through Bugzilla, a popular open source bug tracking system. This page will highlight a few cool features of Bugzilla that may not be immediately obvious and will answer questions about bug entry and searching. The gateway to the Eclipse bug database is: https://bugs.eclipse.org/bugs. It is also linked off of www.eclipse.org.<br />
<br />
==Bug Reporting References==<br />
* [http://www.bugzilla.org/docs/2.22/html/ The Bugzilla Guide] - The user manual for Bugzilla produced by the Bugzilla team.<br />
* [http://www.chiark.greenend.org.uk/%7Esgtatham/bugs.html How to Report Bugs Effectively] - Excellent tips on writing quality bug reports.<br />
* [https://bugs.eclipse.org/bugs/page.cgi?id=bug-writing.html Bug Writing Guidelines] - Bug writing guidelines from the Bugzilla team.<br />
<br />
==Cool Things in Bugzilla==<br />
===Bug Entry Templates===<br />
After filling in some or all of the fields on the new bug form (or the feature request form) you can press the “Remember values as bookmarkable template” button. Following the simple instructions on the resulting page will leave you with a bookmark that will take you to a new bug entry page with the fields filled in with the values you have specified. Hint: The template will include all the fields that you filled in so you may not want to enter Summary or Description text as part of your template.<br />
<br />
===Named, Saved and Bookmarked Queries===<br />
The main query page can be found at https://bugs.eclipse.org/bugs/query.cgi. Near the bottom of the query page you have options to:<br />
<br />
* Remember the current settings as the default for this page each time it is loaded.<br />
* Name the query for reuse later (each user has their own set of named queries).<br />
* Name the query for later reuseand add a link to the named query to your page footer for quick access. <br />
<br />
Use your user preferences link to manage named queries (https://bugs.eclipse.org/bugs/userprefs.cgi?bank=footer). Select a previously saved named query (this combo box only appears near the bottom of the query page if you have at least one named query saved)<br />
<br />
===Bug Counts===<br />
The “Reports” link on the footer of most Bugzilla pages takes you to a form that can summarize bug counts in interesting ways. The link is: https://bugs.eclipse.org/bugs/reports.cgi<br />
<br />
===Form Fill In===<br />
You may want to turn on the form fill in feature of Internet Explorer. This will provide drop down lists for picking values you have commonly entered into text fields in the various Bugzilla forms. This option can be found in the Internet Explorer menus Tools->Internet Options->Content->AutoComplete<br />
<br />
===Autolinkification===<br />
Bugzilla automatically creates hyperlinks for certain text patterns, see http://www.bugzilla.org/docs/tip/html/hintsandtips.html.<br />
Here are some examples of automatically created links: [https://bugs.eclipse.org/bugs/show_bug.cgi?id=2345 Bug 2345] has a [https://bugs.eclipse.org/bugs/show_bug.cgi?id=2345#c4 comment 4] (if linked from bug 2345), or [https://bugs.eclipse.org/bugs/show_bug.cgi?id=2345#c4 bug 2345 comment 4] (if linked from another bug).<br />
<br />
==Folders and Work Flow==<br />
===What is the life cycle of a bug report?===<br />
When a new bug is entered it begins life with a Status of either Unconfirmed for normal users or New for users with commit privileges. The bug is typically assigned to the component owner. The component owner will usually use a query of Status = Unconfirmed or New and Assigned to = me to browse what is essentially the component's inbox. She or he will assign bug reports to developers. Email will be generated to the developer (this part is configurable). (Note that the act of reassigning a bug to somebody changes its status to New). The developer may change unconfirmed bugs to new.<br />
<br />
The assigned developer will “accept” the bug which will change its status to Assigned. After working on the bug the developer will mark the bug as Resolved and will select a resolution (Fixed, Invalid, Wontfix, Worksforme).<br />
<br />
Once a bug is resolved there are still a few states it can transition too. How you choose to use these states will be up to individual teams. In our example, when a test pass comes up a component owner can build a query that searched for resolved bugs. After testing that the fix worked a resolved bug can be transitioned to verified, directly to closed, or in fact, reopened. By searching for bugs with a Status of verified and a resolution of fixed developers can come up with release notes. A verified/fixed bug can then be transitioned to closed. And yes, closed bugs can be reopened if need be. As an added bonus other bug status can be transitioned through verified to closed as well. This gives developers the opportunity to test worksforme claims.<br />
<br />
===How do I find a bug if all I know is the old RPRS PRID===<br />
RPRS is the problem tracking system used by the Eclipse team before we switched to Bugzilla. RPRS PRID's are 7 character ID's with a mix of numbers and letters (e.g. 1GETAYN). The RPRS PRID has been added to the end of each bug report summary (title) that was converted from the old system. So to find a bug report based on the PRID simply perform a search of the summary with the PRID. Searching is covered later on in this FAQ.<br />
<br />
===How can I get my enhancements in the committer's queue?===<br />
Please see 'Why do some bugs stay RESOLVED/LATER for years?'<br />
<br />
===Why do some bugs stay RESOLVED/LATER for years?===<br />
<br />
As quoted from [https://bugs.eclipse.org/bugs/show_bug.cgi?id=157642#c14 Bug 157642 Comment 14]:<br />
<br />
For most committers, there is an effectively unlimited supply of available bug<br />
reports and enhancement requests. How they choose what to work on is<br />
effectively a cost/benefit analysis. Cost in this case is the amount of work<br />
to address it, the work of ongoing maintenance for a new feature, the ripple<br />
cost a new feature may have on downstream projects, performance cost, etc. <br />
Things that increase the "benefit" side include benefits for end-users of<br />
Eclipse applications, benefits for downstream projects, etc. Also, input from<br />
the community in the form of votes, and input from the PMC and from committers<br />
on other projects increase the "benefit" side of the equation. A long-dormant<br />
bug may be reopened either because the cost has gone down (perhaps some<br />
underlying infrastructure is now available that makes the problem easier to<br />
solve), or the benefit has gone up (more requests from users, committers on<br />
other projects, the PMC, etc). If the cost/benefit ratio of a bug does not<br />
change, it may remain unaddressed forever.<br />
<br />
===Why is using RESOLVED/LATER bad?===<br />
Bugzilla provides a better way of handling this: you can leave the bug in the NEW<br />
state, but just update the 'target milestone' to be LATER (each project has its own milestones,<br />
so each project will need to add a target milestone of LATER to make this work). That way,<br />
the bug is still in an OPEN state (as opposed to a CLOSED state, as defined in the <br />
[https://bugs.eclipse.org/bugs/page.cgi?id=fields.html#status bugzilla statuses document])<br />
and as such, comes up in any search looking for open bugs. However, you've still got the<br />
ability to filter out the LATER milestones in your reports, if you want to.<br />
<br />
===Deprecated resolutions===<br />
The LATER and REMIND resolutions are obsolete. Please see [https://bugs.eclipse.org/bugs/show_bug.cgi?id=178923#c75 Bug 178923 Comment 75] for more information.<br />
<br />
<br />
==Bug Entry==<br />
===What is the difference between "Report a new bug" and “Enter a feature request”?===<br />
"Enter a feature request" provides a simplified form to enter information pertaining to a suggested enhancement. Certain fields are automatically saved with default values. When a feature request is entered it is stored in the regular bug database along with the bugs. Feature severities are automatically set to "Enhancement"<br />
<br />
===How are the values for Platform and OS filled in on the bug entry form?===<br />
These fields are set based on information provided automatically by your browser. In general they will reflect the Platform and OS you are using when you enter the bug. Please be sure to change these to accurately reflect the bug you are entering. Feature requests have Platform and OS set to “All”.<br />
<br />
===What is the difference between Severity and Priority?===<br />
Severity is assigned by a user and describes the level of impact the bug is having on them. Priority is assigned by the developer and describes the importance a developer places on fixing the bug. P1 is the highest priority, P5 is the lowest.<br />
==Searching==<br />
<br />
===How do I find a particular bug number?===<br />
There are several ways to do this:<br />
<br />
* Use the Quick Search box on: https://bugs.eclipse.org/bugs.<br />
* Type the bug number in the bug # action box on the footer of most Bugzilla pages.<br />
* Put the bug number in the “Only bugs numbered” field on the main query page at: https://bugs.eclipse.org/bugs/query.cgi<br />
<br />
===How do I search for bugs containing certain text?===<br />
There are several ways to do this:<br />
<br />
* Use the Quick Search box on: https://bugs.eclipse.org/bugs/. This box will only perform a case insensitive search on bug summaries. It will not search descriptions or comments.<br />
* Fill in the “Summary” and/or “A description entry:” fields on the main query page at: https://bugs.eclipse.org/bugs/query.cgi. The “description entry” field will search the initial description and all the comments of a bug report.<br />
<br />
Note that the bug # field in the footer of most Bugzilla pages can not be used to search for text.<br />
<br />
===Query Hints===<br />
The “Status”, “Resolution”, “Platform”, “OpSys”, “Priority” and “Severity” multi-select list boxes on the main query page (https://bugs.eclipse.org/bugs/query.cgi) only need to be set if you want to limit your query to certain values for these fields. If you want to search for bugs with any status no items in the “Status” list should be selected. It is not necessary to select all the items in the list.<br />
<br />
===What is the “My Bugs” link on the footer of most Bugzilla pages?===<br />
This is a predefined query for bugs that are New, Assigned or Reopened and that where reported by or assigned to you. You may not change this predefined query but you can remove the link from your footer using the “prefs” link on the footer.<br />
<br />
==Miscellaneous==<br />
===Why am I getting so much email and how can I make it stop===<br />
Go to the “Change password or user preferences” link off the main page (https://bugs.eclipse.org/bugs/userprefs.cgi) and select Email settings. Change your settings to suite your preferences.<br />
<br />
===What are Keywords===<br />
Key words are a set of defined words that can be associated with a bug report. Quick searches can be done on keywords. The following points should be kept in mind about keywords:<br />
<br />
* They are defined by the Bugzilla maintainer. Send requests for new key words to the Bugzilla maintainer.<br />
* They are case insensitive.<br />
* They can not be added to a bug report when it is first created. They can only be added when editing a bug report.<br />
* The keywords are described at: https://bugs.eclipse.org/bugs/describekeywords.cgi<br />
<br />
[[Category:FAQ]][[Category:How to Contribute]]</div>Codesurgeon.gmail.comhttps://wiki.eclipse.org/index.php?title=ECF_Conference_Call_10.2.2007&diff=53014ECF Conference Call 10.2.20072007-10-02T18:06:54Z<p>Codesurgeon.gmail.com: /* Cola Work Progress */</p>
<hr />
<div>==Agenda==<br />
<br />
===ECF 1.2 scheduled for Friday, Oct 3 on [[ECF Ganymede Roadmap]]===<br />
===File Transfer API work coming out of [[Equinox Summit 2007]]===<br />
===Cola Work Progress===<br />
====Operational Transformations on Multi-Character Modifications====<br />
<br />
*not sufficient to only check index position of operations anymore<br />
*length of insertion offsets following (space-wise, not time) operations<br />
<br />
*modifications to code as of yesterday<br />
**testing required - who has time on Thursday and/or Friday evening?<br />
<br />
*progress looks OK so far - no insurmountable restrictions in sight<br />
<br />
*time-constraints<br />
**detailed secondary documentation, e.g. on the wiki, is not going to be available this week<br />
<br />
===[http://www.eclipse.org/proposals/riena/ Riena Project Proposal] and [[ECF_API_Docs | ECF Remote Services API]]===</div>Codesurgeon.gmail.comhttps://wiki.eclipse.org/index.php?title=ECF/Servers&diff=37643ECF/Servers2007-05-29T15:17:00Z<p>Codesurgeon.gmail.com: fixed broken link to Equinox Servlet Incubator docs</p>
<hr />
<div>==ECF Generic Server==<br />
[[Eclipse Communication Framework Project|ECF]] is currently using the [http://www.eclipse.org/equinox/server/http_in_container.php Equinox Servlet Incubator] to run and support the example collab application running on the 'ECF generic' provider.<br />
<br />
===Connecting to the ECF Generic Server===<br />
#[http://www.eclipse.org/ecf/downloads.php Download] and install the ECF SDK.<br />
#Right-click on a project within your workspace.<br />
#Choose 'ECF' -> 'Connect Project...' from the popup menu.<br />
#Select the 'ECF generic' provider from the list.<br />
#Use '''ecftcp://ecf.eclipse.org:3282/server''' as the connect URI.<br />
#Choose a nickname and then select the 'OK' button.<br />
<br />
===Setting up an ECF Generic Server with Equinox (ECF version 1.0.0M6 or newer)===<br />
<br />
With the following enhancement: [https://bugs.eclipse.org/bugs/show_bug.cgi?id=112890 #112890], it's <br />
possible to configure an ECF generic server by providing a plugin with an extension for the<br />
<b>org.eclipse.ecf.server.generic.configure</b> extension point.<br />
<br />
<ol><br />
<li>Follow instructions for setting up the [http://www.eclipse.org/equinox/server/http_in_container.php Equinox Servlet Incubator]. Note the location of the '''<appserverhome>/webapps/bridge/WEB-INF/platform/plugins''' directory.<br />
</li><br />
<li><b><br />
NOTE: ECF server requires some of the bundles that come from the Equinox core (containing org.eclipse.core.runtime packages and and others). See [http://download.eclipse.org/eclipse/equinox/ Equinox download page] for these bundles.</b><br />
</li><br />
<li>Download and install/deploy ECF bundles to the '''<appserverhome>/webapps/bridge/WEB-INF/platform/plugins''' directory.<br />
</li><br />
<li><br />
Create a new plugin, and add the following extension to this new plugin:<br />
<pre><br />
<extension<br />
point="org.eclipse.ecf.server.generic.configuration"><br />
<connector<br />
hostname="localhost"<br />
keepAlive="30000"<br />
port="3283"><br />
<group<br />
name="server"><br />
</group><br />
</connector><br />
</extension><br />
</pre><br />
<br />
With the above, the server id would be 'ecftcp://localhost:3283/server'.<br />
<br />
Change the values of 'hostname', 'keepAlive', 'port' for the connector, and add groups as desired/appropriate. For example:<br />
<pre><br />
<extension<br />
point="org.eclipse.ecf.server.generic.configuration"><br />
<connector<br />
hostname="ecf.eclipse.org"<br />
keepAlive="20000"<br />
port="9999"><br />
<group<br />
name="groupone"><br />
</group><br />
<group<br />
name="grouptwo"><br />
</group><br />
</connector><br />
</extension><br />
</pre><br />
<br />
With the above, the ids for the two groups would be 'ecftcp://ecf.eclipse.org:9999/groupone' and 'ecftcp://ecf.eclipse.org:9999/grouptwo'.<br />
</li><br />
<li><br />
Build and deploy this new plugin to server plugins directory, along with all the other ECF bundles.<br />
</li><br />
<li>Start the <b>org.eclipse.ecf.server.generic</b> bundle. This can be done via the server console (with ''''start org.eclipse.ecf.server.generic'''') or can be setup to start automatically via the '''<appserverhome>webapps/bridge/WEB-INF/platform/configuration/config.ini''' file. Which is chosen<br />
is dependent upon how one has setup the [http://www.eclipse.org/equinox/server/ Equinox server].<br />
</li><br />
</ol><br />
<br />
===Setting up an ECF Generic Server with Equinox (prior to version 1.0.0M6)===<br />
<br />
<ol><br />
<li>Follow instructions for setting up the [http://www.eclipse.org/equinox/server/http_in_container.php Equinox Servlet Incubator]. Note the location of the '''<appserverhome>/webapps/bridge/WEB-INF/platform/plugins''' directory.<br />
</li><br />
<li><b><br />
NOTE: ECF server requires some of the bundles that come from the Equinox core (containing org.eclipse.core.runtime packages and and others). See [http://download.eclipse.org/eclipse/equinox/ Equinox download page] for these bundles.</b><br />
</li><br />
<li>Download ECF plugins: [http://www.eclipse.org/downloads/download.php?file=/technology/ecf/org.eclipse.ecf.sdk-0.9.6.S20070113.zip ECF 0.9.6] or [http://www.eclipse.org/downloads/download.php ECF Download Page]<br />
#Copy the ECF plugins into the '''<appserverhome>/webapps/bridge/WEB-INF/platform/plugins''' directory created above.<br />
</li><br />
<li>Edit the '''conf/server.xml''' in '''org.eclipse.ecf.server''' plugin (temporarily (0.9.6) you will need to unjar this plugin, edit the server.xml as described below and either re-jar it or create a directory for it...we'll get this fixed in subsequent releases. I've setup bug [https://bugs.eclipse.org/bugs/show_bug.cgi?id=172724 172724] to track this).<br />
<br />
The default content for server.xml is:<br />
<br />
<pre><br />
<server><br />
<!--<br />
<connector protocol="ecftcp" hostname="localhost" port="3282" timeout="30000"><br />
<group name="server"/><br />
</connector><br />
--><br />
</server><br />
</pre><br />
<br />
Notice that this default connector is commented out. You should create connectors like this (from ecf.eclipse.org):<br />
<br />
<pre><br />
<server><br />
<connector protocol="ecftcp" hostname="localhost" port="3282" timeout="30000"><br />
<group name="server"/><br />
<group name="se"/><br />
</connector><br />
</server><br />
</pre><br />
<br />
This sets up two groups, with URLs: <br />
<br />
'''ecftcp://ecf.eclipse.org:3282/server''' and '''ecftcp://ecf.eclipse.org:3282/se'''<br />
<br />
You can add as many groups as you want for a given connector.<br />
</li><br />
<li>Start the org.eclipse.ecf.server bundle. This can be done via the server console (with ''''start org.eclipse.ecf.server'''') or can be setup to start automatically via the '''<appserverhome>webapps/bridge/WEB-INF/platform/configuration/config.ini''' file.<br />
</li><br />
</ol><br />
<br />
[[Category:Eclipse Communication Framework|Servers]]</div>Codesurgeon.gmail.comhttps://wiki.eclipse.org/index.php?title=RT_Shared_Editing&diff=17800RT Shared Editing2006-11-17T21:33:56Z<p>Codesurgeon.gmail.com: ECF:RT Shared Editing moved to RT Shared Editing</p>
<hr />
<div><!-- Introduction --><br />
'''Project Lead''': [http://codesurgeon.blogspot.com/ Mustafa K. Isik]<br />
<br />
'''Mentor(s)''': Scott Lewis, Ken Gilmer<br />
<br />
==Motivation==<br />
The ''RT Shared Editor'', which I'll dub ''Cola'' ('''col'''l'''a'''borate) for now, is supposed to be a tool enabling developers to reap the benefits of pair programming within the Eclipse IDE.<br />
<br />
The term ''pair programming'' describes an activity in which two developers simultaneously work on a single development machine. <br />
<br />
Even though not new to the development community, ''pair programming'' has witnessed a significant rise in adoption over the last years. One of the main reasons being the inclusion to the set of [http://www.extremeprogramming.org/ eXtreme programming (aka ''XP'')] practices. Thus ''pair programming'' is especially, but certainly not only, popular among developers utilizing the values, principles and practices propagated by the ''XP'' methodology.<br />
<br />
The reasoning behind ''pair programming'', as articulated by software developer, author and ''XP'' figurehead [[RT Shared Editing#Resources|Kent Beck (2005 p.42)]] is manifold and pair programmer's activities are described as<br />
*keep each other focused and on task<br />
*brainstorm refinements to the system<br />
*clarify ideas<br />
*take initiative when their partner is stuck, lowering frustration<br />
*hold each other accountable to the team's practices<br />
<br />
From my own experience I can add, that programming in pairs has proved to be beneficial in<br />
*widening developers' horizons and perspectives on perceiving and tackling problems<br />
*increasing trust in one's own skills and generating awareness for areas requiring improvement<br />
*learning from more advanced developers<br />
**improving through working with less experienced devs, motivating to reflect on the essence of one's own practices<br />
*refining one's own communication skills<br />
<br />
===Current Situation===<br />
Tool-support for ''pair programming'' in [http://www.eclipse.org Eclipse] is pretty much non-existent. Pair programming sessions, as spontaneous as they might be arranged in some teams, usually are set up for longer periods of time, ranging anywhere from an hour to some four or five. Pairs consist of locally available developers.<br />
<br />
===Limitations & Problems===<br />
Geographical limitations do not permit for simple pair programming.<br />
Since individuals are required to sit in front of the same machine, they apparently have to be located at offices close to each other.<br />
Thus software development, not being a regionally bound activity, as proven by the sustained success and advances of open-source software and the nature of many open-source teams, has to be carried out without utilizing effective pair programming in many cases.<br />
<br />
Even when developers are located at the same work site, the effort to get two people set up together in front of a computer (drinks, resources, etc.) proves not to be worth for short programming or reviewing tasks, which sometimes are all that is required. This does not mean that coders do not occasionally sit down for such quick tasks, but from personal experience not as often as it might be beneficial for oneself and/or the code.<br />
<br />
Traditional instant messaging software does not lend itself for code communication among developers. Such software generally proves to be fairly feature-limited and catering to different target audiences. Theoretically it would lend itself for sending back and forth short code snippets at best, practically large-scale adoption of such behaviour has yet to be seen.<br />
<br />
Open-plan offices or group cube farm layouts do not support developers in utilizing pair programming benefits either, quickly degrading the workspace noise-level to that of an airport lobby (by the way, the true problem here would be of course the office layout, but the scope of changing that is unfortunately usually beyond the individual developer).<br />
<br />
Furthermore developers, who usually keep book resources in their personal work environment, end up being stripped of those for half of the time they are pair programming.<br />
<br />
===Resolution===<br />
''Cola'' is supposed to support collaborative work on code from disparate locations, minimizing organizational impact and improving on flexibility issues concerning pair programming.<br />
<br />
Developers are intended to be able to work simultaneously on a single source file, viewing changes made by other contributors in real-time and editing the most up-to-date version of the file at all times.<br />
<br />
The initial incarnation of ''Cola'' is to materialize in the form of an Eclipse IDE plug-in.<br />
<br />
==Consistency Maintenance==<br />
Maintaining consistency among shared data in a distributed real-time editing environment is of prime importance.<br />
<br />
Over the last decade a lot of thought has been dedicated to the research of domain-specific issues in real-time collaborative groupware systems. Chengzheng Sun and Clarence Ellis have authored a [[RT Shared Editing#Resources|paper (Sun & Ellis 1998)]] providing a thorough overview of such. The subsequent discussion of challenges specific to real-time collaborative editing is based on the referenced paper and intended to be self-sustaining in that you will not have to dig into academic research material to understand the challenges at hand.<br />
<!-- [[Image:cola_shared_editing_trivial.png|thumb|150px|right|idealistic editing scenario]] --><br />
[[Media:cola_shared_editing_trivial.png|Figure 1]] shows a somewhat ''idealistic'' scenario where communication lag between several editing sites remains without undesired consequences because operations are generated and executed at all sites in an orderly fashion.<br />
In a ''realistic'' distributed editing scenario, as depicted in [[Media:cola_shared_editing_nontrivial.png|Figure 2]], the need for consistency maintenance becomes apparent.<br />
===Challenges===<br />
====Divergence====<br />
<!-- [[Image:cola_shared_editing_nontrivial.png|thumb|400px|left|exemplary editing scenario]] this does not work! could it be that something is wrong with the eclipsepedia configuration? --><br />
Due to dependencies between operations originating from different editors on a shared document and suffering from propagation lag in a distributed environment, shared data state at different sites can divert from each other. This holds especially true for operations that are not [http://en.wikipedia.org/wiki/Commutative commutative] in execution order.<br />
{|border="1" cellpadding="5" cellspacing="0" align="center"<br />
|+''divergence'' in [[Media:cola_shared_editing_divergence.png|Figure 3]]<br />
|-<br />
! style="background:#efefef;" | site 1<br />
! style="background:#ffdead;" | state<br />
! style="background:#efefef;" | site 2<br />
! style="background:#ffdead;" | state<br />
! style="background:#efefef;" | site 3<br />
! style="background:#ffdead;" | state<br />
|-<br />
|A:''insert('a')''||a||A:''insert('a')''||a||A:''insert('a')''||a<br />
|-<br />
|C:''insert('c')''||'''ac'''||B:''insert('b')''||ab||B:''insert('b')''||ab<br />
|-<br />
|B:''insert('b')''||'''acb'''||C:''insert('c')''||'''abc'''||C:''insert('c')''||'''abc'''<br />
|}<br />
<br />
====Causality-violation====<br />
Each editing user's changes need to be communicated to the other editing sites. Independent from message generation times, notification of changes may arrive out-of-order. The resulting artifact for dependent operations is referred to as ''causality-violation''. The order in which operations A and B in [[Media:cola_shared_editing_nontrivial.png|Figure 2]] arrive at site 3 visualizes a typical case of ''causality-violation''. Operation B is generated at site 2 after the arrival and execution of operation A. The reversed arrival order of both operations at site 3 may result in an undefined operation B at site 3 (e.g. B is supposed to delete an insertion commited by A).<br />
Depending on the underlying communications protocol even the in-order arrival of editing operations originating from the same site [[Media:cola_shared_editing_causality.png|might not be guaranteed]].<br />
<br />
====Intention-violation====<br />
''Intention-violation'' is different from ''causality-violation'' in that it refers to the problems that arise when executing an operation on a document state altered by operations not having been executed at the operation's generation site.<br />
<br />
Operation C in [[Media:cola_shared_editing_nontrivial.png|Figure 2]] is defined/generated at site 3 on a document state neither affected by operation A nor B. Upon arrival and execution at sites 2 and 3 the respective document states have already been changed by operations A and B and can cause operation C to commit an unintended and undesired change.<br />
<br />
In contrast to the ''divergence''-problem, ''intention-violation'' cannot be resolved by a simple ''serialization protocol''.<br />
<br />
===Resolution Approach===<br />
====Look at the Sky & Spot JUPITER====<br />
A closer inspection of a paper titled "High-Latency, Low-Bandwidth Windowing in the Jupiter Collaboration System" [[RT Shared Editing#Resources| (Nichols ''et al'' 1995)]] reveals a very interesting approach to solving distributed-state synchronization problems in systems with more than two participating sites. <br />
<br />
Even though functionality-wise the more advanced approaches described in [[RT Shared Editing#Resources|(Sun & Ellis 1998)]] also represent solutions to the challenges in realizing ''Cola'', [[RT Shared Editing#Resources| (Nichols ''et al'' 1995)]] makes assumptions perfectly feasible for ''Cola'''s case that (in relative terms) greatly simplify the required concurrency-control algorithm.<br />
<br />
====Client-Server Communications====<br />
Much of the complexity of for instance the ''GROVE'' and ''REDUCE'' collaboration models stem from the fact, that they are designed for handling arbitrary communication-paths between each editing site. The ''JUPITER'' collaboration system on the other hand is [[Media:cola_client_server.png|designed around a central server]]. Utilizing the resulting communications topology, conflicting messages are resolved on the level of 2-way messaging between ''specific client - central server'' as opposed to [[Media:cola_n_way.png|n-way communications]]. <br />
<br />
Concerning ''causality-violation'', communications being effectively limited to 2-way / routed through the server document state, out-of-order arrival of messages adhering to a causal order, such as deletions referring to prior insertions, is prohibited. The central ordering instance, the server editing site, ensures, that all sites are updated in the right causal order.<br />
<br />
====Network Protocol====<br />
Considering [[Media:cola_shared_editing_causality.png|operations originating from the same site]], ''causality-violation'' of this specific type or more general reversed messaging, can be prohibited by using a ''network protocol'' not permitting for out-of-order communication of operations to the receiving site (either client or server). <br />
''Cola'''s network protocol will be chosen with respect to satisfaction of this property.<br />
<br />
====Optimistic Change Application====<br />
Responsiveness and immediate user feedback are important and expected features in an editor, therefore user operations are applied immediately to the local document state without awaiting server approval or undergoing any modifications.<br />
<br />
====Conflict Resolution via Operational Transformations====<br />
Even with the client-server topology in place and a 2-way messaging protocol ordering communications, preventing the out-of-order arrival of messages causing causality-violation, intention-violation can still occur. <br />
<br />
This becomes apparent when considering, that causality-violation is due to remote messages either from different sites or originating from a single site ''crossing on the wire'' on their way to the unaltered, i.e. consistent in document state concerning all prior operations, recipient. Ensuring the ordered arrival and execution of operations at the receiver site suffices to maintain consistency in document state.<br />
<br />
''Intention-violation'' on the other hand describes problems that occur due to operations being intended for execution on a certain document state, which is not available upon their arrival at the receiver. Locally generated and executed operations have altered the receiving site's document state during the transmission of remote operations. In this scenario, best described as mutually directed messages crossing on the wire, the same problem applies the other way around when exchanging sender and receiver labels on the sites.<br />
<br />
Application of operations on a document state different from the one they'd been intended for, bears the danger of intention violation, ranging from insertions at wrong places to deletion of wrong sections.<br />
Dropping and rolling back operations, in such a highly interactive application domain, is not an option, especially since local operations are executed immediately. <br />
<br />
Therefore ''intention-preserving transformations'' of such operations, i.e. ''operational transformations'', are key to ''Cola's'' resolution approach.<br />
<br />
<tt><br />
'''basic 2-way communication is of the form'''<br />
*client generates operation<br />
*client executes operation locally<br />
*client notifies server of operation<br />
*server receives operation<br />
*''in case of conflict:'' server '''transforms''' operation<br />
*server executes operation locally<br />
*server notifies all other clients of operation<br />
''for every receiving client''<br />
*client receives operation<br />
*''in case of conflict:'' client '''transforms''' operation<br />
*client executes operation locally<br />
</tt><br />
<br />
<br />
Presenting ''operational transformations'' as a means for conflict resolution, several immediate concerns arise<br />
#what ''are'' cola's operations on which to perform transformations<br />
#how do conflicting scenarios look like<br />
#what do operational transformations ''look like'' and<br />
#how are ''conflicts in document state'' to be ''detected'' in order to resolve them via transformations on operations?<br />
<br />
''Cola'' models all editing operations on documents as atomic ''deletions'' and ''insertions'' of single characters. Editing operations on more than a single char are broken down to atomic operations, as listed below.<br />
<pre><br />
&rarr; del(position)<br />
&rarr; del(from_position, to_position):=<br />
for(int i = from_position; i <= to_position; i++){<br />
del(i); <br />
}<br />
&rarr; ins(position, char)<br />
&rarr; ins(from_position, string):=<br />
for(int i = 0; i < string.length; i++){<br />
ins(from_position + i, string[i]);<br />
}<br />
</pre><br />
<br />
<br />
An example serves best to illustrate the features demanded of ''operational transformations''.<br />
<br />
{|border="1" cellpadding="3" cellspacing="0" align="center"<br />
|+''conflicting insertions''<br />
|-<br />
! style="background:#efefef;" | remote op.<br />
! style="background:#efefef;" | local op.<br />
! style="background:#ff8c00;" | state @ client 1<br />
! style="background:#6495ed;" | state @ client 2<br />
! style="background:#efefef;" | local op.<br />
! style="background:#efefef;" | remote op.<br />
|-<br />
| ||<font color=darkorange>ins(2,O)</font>||CRON||CRON||<font color=blue>ins(5,A)</font>|| <br />
|-<br />
|<font color=blue>ins(5,A)</font>|| ||C'''O'''RON||CRON'''A'''|| ||<font color=darkorange>ins(2,O)</font><br />
|-<br />
| || ||CORO<font color=red>'''A'''</font>N||CORON<font color=green>'''A'''</font>|| ||<br />
|}<br />
<br />
The user at site 2 intends to insert an ''A'' after the last ''N''. When the corresponding operation he issued and which was successfully applied to his local document, arrives at site 1 the document state has been altered by the insertion of another character at a lower index, thus shifting all subsequent characters' indeces by one. The untransformed execution of the insertion from site 2 on site 1's document results in intention-violation. The obvious solution in this case would be to increment the insertion op's index by one and executing <tt>ins(6,O)</tt><br />
<br />
Building on the information provided by the knowledge of the document states being one operation apart and knowing which two operations are intended for execution, abstraction and generalization lead to the specific operational transformation for two conflicting insertions. <br />
<br />
With regard to the ''conflicting insertions'' example, and the type of relation defined by transformations on operations, it becomes apparent that the transformation can be precisely described in terms of a function taking two conflicting operations at a time as input parameters and delivering two output operations modified for intention-preserving applicability at their respective destination sites.<br />
<br />
For brevity reasons, I will refer to cola's operational transformation function as '''<tt>coopt</tt>''' function (for '''co'''la '''op'''erational '''t'''ransformation).<br />
<pre><br />
coopt(ins(x, char_1), ins(y, char_2)):=<br />
{(ins(x, char_1), ins(y + 1, char_2)) , for x < y<br />
(ins(x + 1, char_1), ins(y, char_2)) , for x > y<br />
(noop, noop) , for x = y && char_1 == char_2<br />
serverside insertion comes first , for x = y && char_1 != char_2<br />
}<br />
</pre><br />
<br />
Using '''<tt>coopt</tt>''' for resolving the conflict between the insertion operations in our example, yields the same and intention-preserved document state at both sites.<br />
<br />
{|border="1" cellpadding="3" cellspacing="0" align="center"<br />
|+''conflicting insertions resolved via coopt''<br />
|-<br />
! style="background:#efefef;" | remote op.<br />
! style="background:#efefef;" | local op.<br />
! style="background:#ff8c00;" | state @ client 1<br />
! style="background:#6495ed;" | state @ client 2<br />
! style="background:#efefef;" | local op.<br />
! style="background:#efefef;" | remote op.<br />
|-<br />
| ||<font color=darkorange>ins(2,O)</font>||CRON||CRON||<font color=blue>ins(5,A)</font>|| <br />
|-<br />
|'''coopt('''<font color=blue>ins(5,A)</font>''',''' ins(2,O)''')'''<br>&rarr; <font color=blue>ins('''6''',A)</font>|| ||C'''O'''RON||CRON'''A'''|| ||'''coopt('''<font color=darkorange>ins(2,O)</font>''',''' ins(5,A)''')'''<br>&rarr; <font color=darkorange>ins(2,O)</font><br />
|-<br />
| || ||CORON<font color=green>'''A'''</font>||CORON<font color=green>'''A'''</font>|| ||<br />
|}<br />
<br />
Conflicts can also arise for deletions at both sites and deletion and insertion operations executed on the same document state at two different sites.<br />
<br />
{|border="1" cellpadding="3" cellspacing="0" align="center"<br />
|+''conflicting deletions''<br />
|-<br />
! style="background:#efefef;" | remote op.<br />
! style="background:#efefef;" | local op.<br />
! style="background:#ff8c00;" | state @ client 1<br />
! style="background:#6495ed;" | state @ client 2<br />
! style="background:#efefef;" | local op.<br />
! style="background:#efefef;" | remote op.<br />
|-<br />
| ||<font color=darkorange>del(6)</font>||MARIPOSA||MARIPOSA||<font color=blue>del(5)</font>|| <br />
|-<br />
|<font color=blue>del(5)</font>|| ||MARIPSA||MARIOSA|| ||<font color=darkorange>del(6)</font><br />
|-<br />
| || ||MARISA||MARIO<font color=red>'''A'''</font>|| ||<br />
|}<br />
<br />
The specific conflict in the ''conflicting deletions'' table can be resolved by decrementing the index of the <tt>del(6)</tt> operation originating from site 1 by one upon arrival at and prior to execution at site 2.<br />
<br />
As for insertions, '''<tt>coopt</tt>''' handles conflicting deletions in a general way.<br />
<pre><br />
coopt(del(x), del(y):=<br />
{(del(x), del(y - 1) , for x < y<br />
(del(x - 1), del(y) , for x > y<br />
(noop, noop) , for x = y <br />
}<br />
</pre><br />
Transforming remote delete operations defined on document states one operation apart from the local state, results in conflict free convergence.<br />
<br />
{|border="1" cellpadding="3" cellspacing="0" align="center"<br />
|+''conflicting deletions resolved via coopt''<br />
|-<br />
! style="background:#efefef;" | remote op.<br />
! style="background:#efefef;" | local op.<br />
! style="background:#ff8c00;" | state @ client 1<br />
! style="background:#6495ed;" | state @ client 2<br />
! style="background:#efefef;" | local op.<br />
! style="background:#efefef;" | remote op.<br />
|-<br />
| ||<font color=darkorange>del(6)</font>||MARIPOSA||MARIPOSA||<font color=blue>del(5)</font>|| <br />
|-<br />
|'''coopt('''<font color=blue>del(5)</font>''',''' del(6)''')'''<br>&rarr; <font color=blue>del(5)</font>|| ||MARIPSA||MARIOSA|| ||'''coopt('''<font color=darkorange>del(6)</font>''',''' del(5)''')'''<br>&rarr; <font color=darkorange>del('''5''')</font><br />
|-<br />
| || ||MARISA||MARISA|| ||<br />
|}<br />
<br />
''Cola'' provides two more operations, which also need to be handled by '''<tt>coopt</tt>'''. These last operations are intended to improve on the collaborative experience and are of non-editing nature. Both operations are user-specific in that every user's cursor, possibly each in a different color, is replicated among editing sites. This is to make remote user operations more comprehensible for the respective local user. The same applies to the user-specific highlighting of editor contents.<br />
<pre><br />
&rarr; cursor(position, user)<br />
&rarr; highlight(position, user)<br />
&rarr; highlight(from_position, to_position, user):=<br />
for(int i = from_position; i <= to_position; i++){<br />
highlight(i, user); <br />
}<br />
</pre><br />
<br />
====Concurrency Algorithm====<br />
Summarizing the previous section and giving a motivation for the one at hand, ''operational transformations'' are applicable on operations, defined on the same document state at different sites. When reaching their respective destination sites in such scenarios, the remote sites' document state diverges by ''one operation''. The transformation modifies the incoming operation with respect to the operation that has been executed at the receiving site, so that ''intention-preservation'' for the incoming operation is satisfied.<br />
<br />
In cases where the local, receiving document state ''diverges by more than one (locally executed) operation'' compared to the state at a remote site sending an operation, the mechanism of ''operational transformations'' cannot be utilized directly. The previously iterated preconditions for the application of such are not met.<br />
<br />
A ''concurrency algorithm'' takes care of detecting conflicting situations and meeting requirements for resolution via ''operational transformations''.<br />
<br />
[[Media:cola_shared_editing_statespace_simple.png|Figure 4]] features an exemplary graph of the state-space a client and the server editing site roam during a session. The diagram visualizes a scenario where during editing, document states at client and server side diverge by a single operation respectively and get resolved via operational transformations.<br />
<br />
As indicated, the need for a concurrency algorithm arises in part from the non-applicability of operational transformations on document states diverging by more than a single operation, as presented in [[Media:cola_shared_editing_statespace_divergence_by_more_than_one_op.png|Figure 5]]. The graph shows client and server sites diverging as of state <tt>(0,0)</tt>. The client site receives the server message, which it directly transforms via the <tt>coopt</tt>-function and subsequently applies to its document state. Let <tt>c</tt> be the initial client application, and <tt>s1</tt> the first server-site operation. <tt>coopt(c,s1)</tt> results in a 2-tuple <tt>(c',s1')</tt> of which the parameters are characterized by the equation <tt>c &#x2299; s1' = s1 &#x2299; c'</tt> Interpreting the equation, the subsequent application of <tt>s1'</tt> to a document state <tt>c</tt> results in the same state as applying <tt>s1</tt> followed by <tt>c'</tt>. This is by definition the exact thing the operational transformation function <tt>coopt</tt> is to take care of.<br />
The interesting part is when the client receives another message <tt>s2</tt>, having been generated on a document state only incorporating operation <tt>s1</tt>, <tt>s2</tt> cannot be applied to the client state <tt>c &#x2299; s1'</tt> directly. But since the client already contains <tt>s1</tt>, which just had been applied to the client-local state via <tt>s1'</tt> in the previous step, the precondition for conflict-resolution via <tt>coopt</tt>, i.e. divergence by a single operation, is met. <br />
<br />
''The important and central question is what other parameter is supposed to go into <tt>coopt</tt> with <tt>s2</tt>.''<br />
<br />
Considering that the server-state did not contain <tt>c</tt> when generating <tt>s2</tt>, <tt>c</tt> in some form resembles/relates to the deviating operation. With <tt>c'</tt> we are aware of a transformed version of operation <tt>c</tt>, which could be applied to an <tt>s1</tt> document state in an intention-preserving/non-destructive manner. Thus <tt>c'</tt> is to be the other parameter to be respected when transforming operation <tt>s2</tt> for applicability on the client side. [[Media:cola_shared_editing_statespace_divergence_by_more_than_one_op.png|Figure 5]] has concrete operations substituted for <tt>c, s1, and s2</tt>.<br />
<br />
{|border="1" cellpadding="3" cellspacing="0" align="center"<br />
|+''mapping for exemplary operations in Figure 5''<br />
|-<br />
! style="background:#efefef;" | <tt>c</tt><br />
! style="background:#efefef;" | <tt>c'</tt><br />
! style="background:#efefef;" | <tt>c' '</tt><br />
! style="background:#6495ed;" | <tt>s1</tt><br />
! style="background:#6495ed;" | <tt>s1'</tt><br />
! style="background:#ff8c00;" | <tt>s2</tt><br />
! style="background:#ff8c00;" | <tt>s2'</tt><br />
|-<br />
|del(5)||del(5)||del(5)||del(9)||del(8)||del(8)||del(7) <br />
|}<br />
<br />
Assuming that in state <tt>(0,2)</tt> the server receives the client-message originating from state <tt>(0,0)</tt> and communicating the client-operation <tt>c</tt> (i.e. <tt>del(5)</tt> in [[Media:cola_shared_editing_statespace_divergence_by_more_than_one_op.png|Figure 5]]), it becomes once again apparent, that an operational transformation via <tt>coopt(c,s2)</tt> won't suffice to reach consistent document states on client and server sides.<br />
<br />
The server, being in a document state off by more than one diverging operation considering the state on which <tt>c</tt> had been defined, some course of action is needed to transform <tt>c</tt> with respect to all operations, that have already been applied on the server state, i.e. regarding not only <tt>s2</tt>, but also <tt>s1</tt>.<br />
<br />
''obtaining an intention-preserving instance of operation <tt>c</tt> for application on state <tt>(0,2)</tt>''<br />
<pre><br />
coopt(c,s1)&rarr;(c',s1'); //use c' for transformation against s2<br />
&rArr; coopt(c',s2)&rarr;(c'',s2'); //c'' is OK for application on state (0,2)<br />
</pre><br />
''different notation for the same procedure''<br />
<pre><br />
applyLeftOfResult(coopt(leftOfResult(coopt(c,s1)&rarr;(c',s1')),s2) &rarr; (c'',s2'));<br />
</pre><br />
[[Media:cola_shared_editing_statespace_divergence_by_more_than_one_op_closure.png|Figure 6]] extends the editing scenario accordingly.<br />
=====the algorithm=====<br />
Having closely inspected an example where operational transformations cannot be utilized directly to resolve conflicting situations, we understand the need for an ''encapsulating'' algorithm, taking care of meeting the proper preconditions for the application of '''<tt>coopt</tt>'''.<br />
<br />
Interpreting the state-space graph in [[Media:cola_shared_editing_statespace_algorithm_client_perspective.png|Figure 7]] as how a client perceives an editing session and the processing of local and incoming operations, leads to the required functionality of the controlling ''concurrency algorithm''. From the client's perspective the server was last known to be in state <tt>(x,y)</tt>. The client state has moved on by <tt>k</tt> locally generated and executed operations since the last server-to-client communication. All <tt>k</tt> messages generated by the client have been communicated to the server, so that the next server-generated message is to originate from one of the states between <tt>(x,y)</tt> and <tt>(x+'''k''',y)</tt>. As demonstrated in the introductory example to this subsection, an incoming operation, originating from a state <tt>(x+'''i''',y)</tt>, where i &isin; {0,..,(k-1)}, could not be directly <tt>coopt</tt>'ed with the most recent client operation '''<tt>k</tt>'''. Instead the received server operation has to be consecutively <tt>coopt</tt>'ed with each operation starting with the one generated by the client on the same state as the server operation originated from, leading up to and including the state of operation <tt>k-1</tt>. That is each succeeding <tt>coopt</tt> is called with the result of the transformed server message from the preceding <tt>coopt</tt> and the respective state's local operation. The last <tt>coopt</tt>, which is '''<tt>coopt(i*, k)</tt>''', where ''i* := indicates properly transformed server message/operation i'', yields the intention-preserving transformed operation <tt>i^(*+1)</tt> applicable on the client state and taking it to state '''<tt>(x+k, y+1)</tt>'''. <br />
<br />
Since the ''cola'' architecture is designed to have the server only differ from the clients in that it serves as central notification instance, the algorithm also applies to the server site.<br />
<br />
<br />
<br />
==Integration into Eclipse Communication Framework==<br />
The '''org.eclipse.ecf.example.collab.editor''' plugin provides a [[Example_Shared_Text_Editor|shared editor]] implementation based on the [[Eclipse_Communication_Framework_Project|Eclipse Communication Framework]]. <br />
<br />
It differs from the ''cola'' approach in that it does not utilize advanced mechanisms, such as ''operational transformations'' and a ''concurrency algorithm'', to ensure consistency in document states at discrete sites while maintaining the effects of every editing operation.<br />
Instead of communicating atomic editing operations to each remote site, where state-specific transformations ensure consistent applicability, the [[Example_Shared_Text_Editor|exemplary shared editor]] sends the entire document content to session participants upon local application of an operation. The incoming document overwrites each receiver's copy. In case of communications ''crossing on the wire'', editing information is lost and document states divert.<br />
<br />
In order to maximize code reuse, ''cola's'' sample implementation, '''org.eclipse.ecf.example.sharededitor.cola''', builds on the prior [[Example_Shared_Text_Editor|shared editor]], modifying and extending its functionality as needed. Thus, once deployed and even though the core communications are handled very differently, setting up and running either editor is very much alike.<br />
<br />
===Take a Sip===<br />
====The Cola Source====<br />
''Cola's'' current incarnation lives in a CVS repository at the [http://osuosl.org/ Oregon State University Open Source Lab]. You can get your hands on the sourcecode via anonymous access.<br />
<pre><br />
==server & repository names==<br />
:pserver:anonymous@ecf1.osuosl.org:/ecf<br />
</pre><br />
<pre><br />
==path within repo==<br />
/applications/org.eclipse.ecf.example.sharededitor.cola<br />
</pre><br />
<br />
====Set it Up & Get it Running====<br />
As for obtaining the rest of the code required to build and run ''cola'', consult the [http://www.eclipse.org/ecf/resources.html ECF development resources page] and get the latest sources. A ''team project set'' is provided to greatly simplify your workspace setup.<br />
<br />
Consult the straightforward [[Example_Shared_Text_Editor|how-to]] on the prior shared editor, selecting the ''cola''-specific menu entries at steps '''5.''' and '''7.''', to set up a ''cola'' editing session.<br />
<br />
''Cola'' is stable and functional apart from some minor restrictions, which are being worked on. Currently the following restrictions apply:<br />
*document sharing is limited to two sites<br />
*both participants have to join, prior to editing<br />
*multi-character operations, such as copy & paste of multiple characters or bulk deletion of such, are yet to be implemented.<br />
<br />
==Resources==<br />
===Meeting Notes=== <br />
*[[Eclipse_Communication_Framework_Project|ECF Conference Calls]]<br />
*[[Monday May 29, 2006]]<br />
<br />
===Papers & Books===<br />
*Beck, K 2005, ''Extreme Programming Explained - Embrace Change'', 2nd Ed., Addison-Wesley, Boston MA (USA), p. 42<br />
*Sun, C & Ellis, C 1998, [http://citeseer.ist.psu.edu/sun98operational.html ''Operational Transformation in Real-Time Group Editors: Issues, Algorithms, and Achievements''], Proceedings of the ACM Conference on Computer-Supported Cooperative Work, Seattle WA (USA), pp. 59-68<br />
*Nichols, D, Curtis, P, Dixon, M & Lamping, J 1995, [http://portal.acm.org/citation.cfm?coll=GUIDE&dl=GUIDE&id=215706 ''High-Latency, low-bandwidth windowing in the Jupiter collaboration system''], Proceedings of the 8th annual ACM symposium on User interface and software technology, Pittsburgh PA (USA), pp. 111-120<br />
<br />
[[Category: Eclipse Communication Framework|Real-Time Shared Editing]]</div>Codesurgeon.gmail.comhttps://wiki.eclipse.org/index.php?title=ECF:RT_Shared_Editing&diff=17801ECF:RT Shared Editing2006-11-17T21:33:56Z<p>Codesurgeon.gmail.com: ECF:RT Shared Editing moved to RT Shared Editing: Undoing Move</p>
<hr />
<div>#redirect [[RT Shared Editing]]</div>Codesurgeon.gmail.comhttps://wiki.eclipse.org/index.php?title=Talk:RT_Shared_Editing&diff=17802Talk:RT Shared Editing2006-11-17T21:33:56Z<p>Codesurgeon.gmail.com: Talk:ECF:RT Shared Editing moved to Talk:RT Shared Editing</p>
<hr />
<div>I use the term ''co-programming'' to talk about two people closely collaborating via two separate machines to distinguish it from ''pair programming'' where two people work via the same machine.<br />
- Bjorn<br />
<br />
== pair programming vs. co-programming ==<br />
<br />
Thanks for your input Bjorn. Even though your differentiation makes sense, I'm still inclined to use the term 'pair programming', since it is widely known and the name of the practice to be initially supported by ''Cola''. - Mustafa</div>Codesurgeon.gmail.comhttps://wiki.eclipse.org/index.php?title=Talk:ECF:RT_Shared_Editing&diff=17803Talk:ECF:RT Shared Editing2006-11-17T21:33:56Z<p>Codesurgeon.gmail.com: Talk:ECF:RT Shared Editing moved to Talk:RT Shared Editing: Undoing Move</p>
<hr />
<div>#redirect [[Talk:RT Shared Editing]]</div>Codesurgeon.gmail.comhttps://wiki.eclipse.org/index.php?title=Talk:RT_Shared_Editing&diff=17796Talk:RT Shared Editing2006-11-17T21:15:45Z<p>Codesurgeon.gmail.com: Talk:RT Shared Editing moved to Talk:ECF:RT Shared Editing</p>
<hr />
<div>I use the term ''co-programming'' to talk about two people closely collaborating via two separate machines to distinguish it from ''pair programming'' where two people work via the same machine.<br />
- Bjorn<br />
<br />
== pair programming vs. co-programming ==<br />
<br />
Thanks for your input Bjorn. Even though your differentiation makes sense, I'm still inclined to use the term 'pair programming', since it is widely known and the name of the practice to be initially supported by ''Cola''. - Mustafa</div>Codesurgeon.gmail.comhttps://wiki.eclipse.org/index.php?title=RT_Shared_Editing&diff=17794RT Shared Editing2006-11-17T21:15:44Z<p>Codesurgeon.gmail.com: RT Shared Editing moved to ECF:RT Shared Editing</p>
<hr />
<div><!-- Introduction --><br />
'''Project Lead''': [http://codesurgeon.blogspot.com/ Mustafa K. Isik]<br />
<br />
'''Mentor(s)''': Scott Lewis, Ken Gilmer<br />
<br />
==Motivation==<br />
The ''RT Shared Editor'', which I'll dub ''Cola'' ('''col'''l'''a'''borate) for now, is supposed to be a tool enabling developers to reap the benefits of pair programming within the Eclipse IDE.<br />
<br />
The term ''pair programming'' describes an activity in which two developers simultaneously work on a single development machine. <br />
<br />
Even though not new to the development community, ''pair programming'' has witnessed a significant rise in adoption over the last years. One of the main reasons being the inclusion to the set of [http://www.extremeprogramming.org/ eXtreme programming (aka ''XP'')] practices. Thus ''pair programming'' is especially, but certainly not only, popular among developers utilizing the values, principles and practices propagated by the ''XP'' methodology.<br />
<br />
The reasoning behind ''pair programming'', as articulated by software developer, author and ''XP'' figurehead [[RT Shared Editing#Resources|Kent Beck (2005 p.42)]] is manifold and pair programmer's activities are described as<br />
*keep each other focused and on task<br />
*brainstorm refinements to the system<br />
*clarify ideas<br />
*take initiative when their partner is stuck, lowering frustration<br />
*hold each other accountable to the team's practices<br />
<br />
From my own experience I can add, that programming in pairs has proved to be beneficial in<br />
*widening developers' horizons and perspectives on perceiving and tackling problems<br />
*increasing trust in one's own skills and generating awareness for areas requiring improvement<br />
*learning from more advanced developers<br />
**improving through working with less experienced devs, motivating to reflect on the essence of one's own practices<br />
*refining one's own communication skills<br />
<br />
===Current Situation===<br />
Tool-support for ''pair programming'' in [http://www.eclipse.org Eclipse] is pretty much non-existent. Pair programming sessions, as spontaneous as they might be arranged in some teams, usually are set up for longer periods of time, ranging anywhere from an hour to some four or five. Pairs consist of locally available developers.<br />
<br />
===Limitations & Problems===<br />
Geographical limitations do not permit for simple pair programming.<br />
Since individuals are required to sit in front of the same machine, they apparently have to be located at offices close to each other.<br />
Thus software development, not being a regionally bound activity, as proven by the sustained success and advances of open-source software and the nature of many open-source teams, has to be carried out without utilizing effective pair programming in many cases.<br />
<br />
Even when developers are located at the same work site, the effort to get two people set up together in front of a computer (drinks, resources, etc.) proves not to be worth for short programming or reviewing tasks, which sometimes are all that is required. This does not mean that coders do not occasionally sit down for such quick tasks, but from personal experience not as often as it might be beneficial for oneself and/or the code.<br />
<br />
Traditional instant messaging software does not lend itself for code communication among developers. Such software generally proves to be fairly feature-limited and catering to different target audiences. Theoretically it would lend itself for sending back and forth short code snippets at best, practically large-scale adoption of such behaviour has yet to be seen.<br />
<br />
Open-plan offices or group cube farm layouts do not support developers in utilizing pair programming benefits either, quickly degrading the workspace noise-level to that of an airport lobby (by the way, the true problem here would be of course the office layout, but the scope of changing that is unfortunately usually beyond the individual developer).<br />
<br />
Furthermore developers, who usually keep book resources in their personal work environment, end up being stripped of those for half of the time they are pair programming.<br />
<br />
===Resolution===<br />
''Cola'' is supposed to support collaborative work on code from disparate locations, minimizing organizational impact and improving on flexibility issues concerning pair programming.<br />
<br />
Developers are intended to be able to work simultaneously on a single source file, viewing changes made by other contributors in real-time and editing the most up-to-date version of the file at all times.<br />
<br />
The initial incarnation of ''Cola'' is to materialize in the form of an Eclipse IDE plug-in.<br />
<br />
==Consistency Maintenance==<br />
Maintaining consistency among shared data in a distributed real-time editing environment is of prime importance.<br />
<br />
Over the last decade a lot of thought has been dedicated to the research of domain-specific issues in real-time collaborative groupware systems. Chengzheng Sun and Clarence Ellis have authored a [[RT Shared Editing#Resources|paper (Sun & Ellis 1998)]] providing a thorough overview of such. The subsequent discussion of challenges specific to real-time collaborative editing is based on the referenced paper and intended to be self-sustaining in that you will not have to dig into academic research material to understand the challenges at hand.<br />
<!-- [[Image:cola_shared_editing_trivial.png|thumb|150px|right|idealistic editing scenario]] --><br />
[[Media:cola_shared_editing_trivial.png|Figure 1]] shows a somewhat ''idealistic'' scenario where communication lag between several editing sites remains without undesired consequences because operations are generated and executed at all sites in an orderly fashion.<br />
In a ''realistic'' distributed editing scenario, as depicted in [[Media:cola_shared_editing_nontrivial.png|Figure 2]], the need for consistency maintenance becomes apparent.<br />
===Challenges===<br />
====Divergence====<br />
<!-- [[Image:cola_shared_editing_nontrivial.png|thumb|400px|left|exemplary editing scenario]] this does not work! could it be that something is wrong with the eclipsepedia configuration? --><br />
Due to dependencies between operations originating from different editors on a shared document and suffering from propagation lag in a distributed environment, shared data state at different sites can divert from each other. This holds especially true for operations that are not [http://en.wikipedia.org/wiki/Commutative commutative] in execution order.<br />
{|border="1" cellpadding="5" cellspacing="0" align="center"<br />
|+''divergence'' in [[Media:cola_shared_editing_divergence.png|Figure 3]]<br />
|-<br />
! style="background:#efefef;" | site 1<br />
! style="background:#ffdead;" | state<br />
! style="background:#efefef;" | site 2<br />
! style="background:#ffdead;" | state<br />
! style="background:#efefef;" | site 3<br />
! style="background:#ffdead;" | state<br />
|-<br />
|A:''insert('a')''||a||A:''insert('a')''||a||A:''insert('a')''||a<br />
|-<br />
|C:''insert('c')''||'''ac'''||B:''insert('b')''||ab||B:''insert('b')''||ab<br />
|-<br />
|B:''insert('b')''||'''acb'''||C:''insert('c')''||'''abc'''||C:''insert('c')''||'''abc'''<br />
|}<br />
<br />
====Causality-violation====<br />
Each editing user's changes need to be communicated to the other editing sites. Independent from message generation times, notification of changes may arrive out-of-order. The resulting artifact for dependent operations is referred to as ''causality-violation''. The order in which operations A and B in [[Media:cola_shared_editing_nontrivial.png|Figure 2]] arrive at site 3 visualizes a typical case of ''causality-violation''. Operation B is generated at site 2 after the arrival and execution of operation A. The reversed arrival order of both operations at site 3 may result in an undefined operation B at site 3 (e.g. B is supposed to delete an insertion commited by A).<br />
Depending on the underlying communications protocol even the in-order arrival of editing operations originating from the same site [[Media:cola_shared_editing_causality.png|might not be guaranteed]].<br />
<br />
====Intention-violation====<br />
''Intention-violation'' is different from ''causality-violation'' in that it refers to the problems that arise when executing an operation on a document state altered by operations not having been executed at the operation's generation site.<br />
<br />
Operation C in [[Media:cola_shared_editing_nontrivial.png|Figure 2]] is defined/generated at site 3 on a document state neither affected by operation A nor B. Upon arrival and execution at sites 2 and 3 the respective document states have already been changed by operations A and B and can cause operation C to commit an unintended and undesired change.<br />
<br />
In contrast to the ''divergence''-problem, ''intention-violation'' cannot be resolved by a simple ''serialization protocol''.<br />
<br />
===Resolution Approach===<br />
====Look at the Sky & Spot JUPITER====<br />
A closer inspection of a paper titled "High-Latency, Low-Bandwidth Windowing in the Jupiter Collaboration System" [[RT Shared Editing#Resources| (Nichols ''et al'' 1995)]] reveals a very interesting approach to solving distributed-state synchronization problems in systems with more than two participating sites. <br />
<br />
Even though functionality-wise the more advanced approaches described in [[RT Shared Editing#Resources|(Sun & Ellis 1998)]] also represent solutions to the challenges in realizing ''Cola'', [[RT Shared Editing#Resources| (Nichols ''et al'' 1995)]] makes assumptions perfectly feasible for ''Cola'''s case that (in relative terms) greatly simplify the required concurrency-control algorithm.<br />
<br />
====Client-Server Communications====<br />
Much of the complexity of for instance the ''GROVE'' and ''REDUCE'' collaboration models stem from the fact, that they are designed for handling arbitrary communication-paths between each editing site. The ''JUPITER'' collaboration system on the other hand is [[Media:cola_client_server.png|designed around a central server]]. Utilizing the resulting communications topology, conflicting messages are resolved on the level of 2-way messaging between ''specific client - central server'' as opposed to [[Media:cola_n_way.png|n-way communications]]. <br />
<br />
Concerning ''causality-violation'', communications being effectively limited to 2-way / routed through the server document state, out-of-order arrival of messages adhering to a causal order, such as deletions referring to prior insertions, is prohibited. The central ordering instance, the server editing site, ensures, that all sites are updated in the right causal order.<br />
<br />
====Network Protocol====<br />
Considering [[Media:cola_shared_editing_causality.png|operations originating from the same site]], ''causality-violation'' of this specific type or more general reversed messaging, can be prohibited by using a ''network protocol'' not permitting for out-of-order communication of operations to the receiving site (either client or server). <br />
''Cola'''s network protocol will be chosen with respect to satisfaction of this property.<br />
<br />
====Optimistic Change Application====<br />
Responsiveness and immediate user feedback are important and expected features in an editor, therefore user operations are applied immediately to the local document state without awaiting server approval or undergoing any modifications.<br />
<br />
====Conflict Resolution via Operational Transformations====<br />
Even with the client-server topology in place and a 2-way messaging protocol ordering communications, preventing the out-of-order arrival of messages causing causality-violation, intention-violation can still occur. <br />
<br />
This becomes apparent when considering, that causality-violation is due to remote messages either from different sites or originating from a single site ''crossing on the wire'' on their way to the unaltered, i.e. consistent in document state concerning all prior operations, recipient. Ensuring the ordered arrival and execution of operations at the receiver site suffices to maintain consistency in document state.<br />
<br />
''Intention-violation'' on the other hand describes problems that occur due to operations being intended for execution on a certain document state, which is not available upon their arrival at the receiver. Locally generated and executed operations have altered the receiving site's document state during the transmission of remote operations. In this scenario, best described as mutually directed messages crossing on the wire, the same problem applies the other way around when exchanging sender and receiver labels on the sites.<br />
<br />
Application of operations on a document state different from the one they'd been intended for, bears the danger of intention violation, ranging from insertions at wrong places to deletion of wrong sections.<br />
Dropping and rolling back operations, in such a highly interactive application domain, is not an option, especially since local operations are executed immediately. <br />
<br />
Therefore ''intention-preserving transformations'' of such operations, i.e. ''operational transformations'', are key to ''Cola's'' resolution approach.<br />
<br />
<tt><br />
'''basic 2-way communication is of the form'''<br />
*client generates operation<br />
*client executes operation locally<br />
*client notifies server of operation<br />
*server receives operation<br />
*''in case of conflict:'' server '''transforms''' operation<br />
*server executes operation locally<br />
*server notifies all other clients of operation<br />
''for every receiving client''<br />
*client receives operation<br />
*''in case of conflict:'' client '''transforms''' operation<br />
*client executes operation locally<br />
</tt><br />
<br />
<br />
Presenting ''operational transformations'' as a means for conflict resolution, several immediate concerns arise<br />
#what ''are'' cola's operations on which to perform transformations<br />
#how do conflicting scenarios look like<br />
#what do operational transformations ''look like'' and<br />
#how are ''conflicts in document state'' to be ''detected'' in order to resolve them via transformations on operations?<br />
<br />
''Cola'' models all editing operations on documents as atomic ''deletions'' and ''insertions'' of single characters. Editing operations on more than a single char are broken down to atomic operations, as listed below.<br />
<pre><br />
&rarr; del(position)<br />
&rarr; del(from_position, to_position):=<br />
for(int i = from_position; i <= to_position; i++){<br />
del(i); <br />
}<br />
&rarr; ins(position, char)<br />
&rarr; ins(from_position, string):=<br />
for(int i = 0; i < string.length; i++){<br />
ins(from_position + i, string[i]);<br />
}<br />
</pre><br />
<br />
<br />
An example serves best to illustrate the features demanded of ''operational transformations''.<br />
<br />
{|border="1" cellpadding="3" cellspacing="0" align="center"<br />
|+''conflicting insertions''<br />
|-<br />
! style="background:#efefef;" | remote op.<br />
! style="background:#efefef;" | local op.<br />
! style="background:#ff8c00;" | state @ client 1<br />
! style="background:#6495ed;" | state @ client 2<br />
! style="background:#efefef;" | local op.<br />
! style="background:#efefef;" | remote op.<br />
|-<br />
| ||<font color=darkorange>ins(2,O)</font>||CRON||CRON||<font color=blue>ins(5,A)</font>|| <br />
|-<br />
|<font color=blue>ins(5,A)</font>|| ||C'''O'''RON||CRON'''A'''|| ||<font color=darkorange>ins(2,O)</font><br />
|-<br />
| || ||CORO<font color=red>'''A'''</font>N||CORON<font color=green>'''A'''</font>|| ||<br />
|}<br />
<br />
The user at site 2 intends to insert an ''A'' after the last ''N''. When the corresponding operation he issued and which was successfully applied to his local document, arrives at site 1 the document state has been altered by the insertion of another character at a lower index, thus shifting all subsequent characters' indeces by one. The untransformed execution of the insertion from site 2 on site 1's document results in intention-violation. The obvious solution in this case would be to increment the insertion op's index by one and executing <tt>ins(6,O)</tt><br />
<br />
Building on the information provided by the knowledge of the document states being one operation apart and knowing which two operations are intended for execution, abstraction and generalization lead to the specific operational transformation for two conflicting insertions. <br />
<br />
With regard to the ''conflicting insertions'' example, and the type of relation defined by transformations on operations, it becomes apparent that the transformation can be precisely described in terms of a function taking two conflicting operations at a time as input parameters and delivering two output operations modified for intention-preserving applicability at their respective destination sites.<br />
<br />
For brevity reasons, I will refer to cola's operational transformation function as '''<tt>coopt</tt>''' function (for '''co'''la '''op'''erational '''t'''ransformation).<br />
<pre><br />
coopt(ins(x, char_1), ins(y, char_2)):=<br />
{(ins(x, char_1), ins(y + 1, char_2)) , for x < y<br />
(ins(x + 1, char_1), ins(y, char_2)) , for x > y<br />
(noop, noop) , for x = y && char_1 == char_2<br />
serverside insertion comes first , for x = y && char_1 != char_2<br />
}<br />
</pre><br />
<br />
Using '''<tt>coopt</tt>''' for resolving the conflict between the insertion operations in our example, yields the same and intention-preserved document state at both sites.<br />
<br />
{|border="1" cellpadding="3" cellspacing="0" align="center"<br />
|+''conflicting insertions resolved via coopt''<br />
|-<br />
! style="background:#efefef;" | remote op.<br />
! style="background:#efefef;" | local op.<br />
! style="background:#ff8c00;" | state @ client 1<br />
! style="background:#6495ed;" | state @ client 2<br />
! style="background:#efefef;" | local op.<br />
! style="background:#efefef;" | remote op.<br />
|-<br />
| ||<font color=darkorange>ins(2,O)</font>||CRON||CRON||<font color=blue>ins(5,A)</font>|| <br />
|-<br />
|'''coopt('''<font color=blue>ins(5,A)</font>''',''' ins(2,O)''')'''<br>&rarr; <font color=blue>ins('''6''',A)</font>|| ||C'''O'''RON||CRON'''A'''|| ||'''coopt('''<font color=darkorange>ins(2,O)</font>''',''' ins(5,A)''')'''<br>&rarr; <font color=darkorange>ins(2,O)</font><br />
|-<br />
| || ||CORON<font color=green>'''A'''</font>||CORON<font color=green>'''A'''</font>|| ||<br />
|}<br />
<br />
Conflicts can also arise for deletions at both sites and deletion and insertion operations executed on the same document state at two different sites.<br />
<br />
{|border="1" cellpadding="3" cellspacing="0" align="center"<br />
|+''conflicting deletions''<br />
|-<br />
! style="background:#efefef;" | remote op.<br />
! style="background:#efefef;" | local op.<br />
! style="background:#ff8c00;" | state @ client 1<br />
! style="background:#6495ed;" | state @ client 2<br />
! style="background:#efefef;" | local op.<br />
! style="background:#efefef;" | remote op.<br />
|-<br />
| ||<font color=darkorange>del(6)</font>||MARIPOSA||MARIPOSA||<font color=blue>del(5)</font>|| <br />
|-<br />
|<font color=blue>del(5)</font>|| ||MARIPSA||MARIOSA|| ||<font color=darkorange>del(6)</font><br />
|-<br />
| || ||MARISA||MARIO<font color=red>'''A'''</font>|| ||<br />
|}<br />
<br />
The specific conflict in the ''conflicting deletions'' table can be resolved by decrementing the index of the <tt>del(6)</tt> operation originating from site 1 by one upon arrival at and prior to execution at site 2.<br />
<br />
As for insertions, '''<tt>coopt</tt>''' handles conflicting deletions in a general way.<br />
<pre><br />
coopt(del(x), del(y):=<br />
{(del(x), del(y - 1) , for x < y<br />
(del(x - 1), del(y) , for x > y<br />
(noop, noop) , for x = y <br />
}<br />
</pre><br />
Transforming remote delete operations defined on document states one operation apart from the local state, results in conflict free convergence.<br />
<br />
{|border="1" cellpadding="3" cellspacing="0" align="center"<br />
|+''conflicting deletions resolved via coopt''<br />
|-<br />
! style="background:#efefef;" | remote op.<br />
! style="background:#efefef;" | local op.<br />
! style="background:#ff8c00;" | state @ client 1<br />
! style="background:#6495ed;" | state @ client 2<br />
! style="background:#efefef;" | local op.<br />
! style="background:#efefef;" | remote op.<br />
|-<br />
| ||<font color=darkorange>del(6)</font>||MARIPOSA||MARIPOSA||<font color=blue>del(5)</font>|| <br />
|-<br />
|'''coopt('''<font color=blue>del(5)</font>''',''' del(6)''')'''<br>&rarr; <font color=blue>del(5)</font>|| ||MARIPSA||MARIOSA|| ||'''coopt('''<font color=darkorange>del(6)</font>''',''' del(5)''')'''<br>&rarr; <font color=darkorange>del('''5''')</font><br />
|-<br />
| || ||MARISA||MARISA|| ||<br />
|}<br />
<br />
''Cola'' provides two more operations, which also need to be handled by '''<tt>coopt</tt>'''. These last operations are intended to improve on the collaborative experience and are of non-editing nature. Both operations are user-specific in that every user's cursor, possibly each in a different color, is replicated among editing sites. This is to make remote user operations more comprehensible for the respective local user. The same applies to the user-specific highlighting of editor contents.<br />
<pre><br />
&rarr; cursor(position, user)<br />
&rarr; highlight(position, user)<br />
&rarr; highlight(from_position, to_position, user):=<br />
for(int i = from_position; i <= to_position; i++){<br />
highlight(i, user); <br />
}<br />
</pre><br />
<br />
====Concurrency Algorithm====<br />
Summarizing the previous section and giving a motivation for the one at hand, ''operational transformations'' are applicable on operations, defined on the same document state at different sites. When reaching their respective destination sites in such scenarios, the remote sites' document state diverges by ''one operation''. The transformation modifies the incoming operation with respect to the operation that has been executed at the receiving site, so that ''intention-preservation'' for the incoming operation is satisfied.<br />
<br />
In cases where the local, receiving document state ''diverges by more than one (locally executed) operation'' compared to the state at a remote site sending an operation, the mechanism of ''operational transformations'' cannot be utilized directly. The previously iterated preconditions for the application of such are not met.<br />
<br />
A ''concurrency algorithm'' takes care of detecting conflicting situations and meeting requirements for resolution via ''operational transformations''.<br />
<br />
[[Media:cola_shared_editing_statespace_simple.png|Figure 4]] features an exemplary graph of the state-space a client and the server editing site roam during a session. The diagram visualizes a scenario where during editing, document states at client and server side diverge by a single operation respectively and get resolved via operational transformations.<br />
<br />
As indicated, the need for a concurrency algorithm arises in part from the non-applicability of operational transformations on document states diverging by more than a single operation, as presented in [[Media:cola_shared_editing_statespace_divergence_by_more_than_one_op.png|Figure 5]]. The graph shows client and server sites diverging as of state <tt>(0,0)</tt>. The client site receives the server message, which it directly transforms via the <tt>coopt</tt>-function and subsequently applies to its document state. Let <tt>c</tt> be the initial client application, and <tt>s1</tt> the first server-site operation. <tt>coopt(c,s1)</tt> results in a 2-tuple <tt>(c',s1')</tt> of which the parameters are characterized by the equation <tt>c &#x2299; s1' = s1 &#x2299; c'</tt> Interpreting the equation, the subsequent application of <tt>s1'</tt> to a document state <tt>c</tt> results in the same state as applying <tt>s1</tt> followed by <tt>c'</tt>. This is by definition the exact thing the operational transformation function <tt>coopt</tt> is to take care of.<br />
The interesting part is when the client receives another message <tt>s2</tt>, having been generated on a document state only incorporating operation <tt>s1</tt>, <tt>s2</tt> cannot be applied to the client state <tt>c &#x2299; s1'</tt> directly. But since the client already contains <tt>s1</tt>, which just had been applied to the client-local state via <tt>s1'</tt> in the previous step, the precondition for conflict-resolution via <tt>coopt</tt>, i.e. divergence by a single operation, is met. <br />
<br />
''The important and central question is what other parameter is supposed to go into <tt>coopt</tt> with <tt>s2</tt>.''<br />
<br />
Considering that the server-state did not contain <tt>c</tt> when generating <tt>s2</tt>, <tt>c</tt> in some form resembles/relates to the deviating operation. With <tt>c'</tt> we are aware of a transformed version of operation <tt>c</tt>, which could be applied to an <tt>s1</tt> document state in an intention-preserving/non-destructive manner. Thus <tt>c'</tt> is to be the other parameter to be respected when transforming operation <tt>s2</tt> for applicability on the client side. [[Media:cola_shared_editing_statespace_divergence_by_more_than_one_op.png|Figure 5]] has concrete operations substituted for <tt>c, s1, and s2</tt>.<br />
<br />
{|border="1" cellpadding="3" cellspacing="0" align="center"<br />
|+''mapping for exemplary operations in Figure 5''<br />
|-<br />
! style="background:#efefef;" | <tt>c</tt><br />
! style="background:#efefef;" | <tt>c'</tt><br />
! style="background:#efefef;" | <tt>c' '</tt><br />
! style="background:#6495ed;" | <tt>s1</tt><br />
! style="background:#6495ed;" | <tt>s1'</tt><br />
! style="background:#ff8c00;" | <tt>s2</tt><br />
! style="background:#ff8c00;" | <tt>s2'</tt><br />
|-<br />
|del(5)||del(5)||del(5)||del(9)||del(8)||del(8)||del(7) <br />
|}<br />
<br />
Assuming that in state <tt>(0,2)</tt> the server receives the client-message originating from state <tt>(0,0)</tt> and communicating the client-operation <tt>c</tt> (i.e. <tt>del(5)</tt> in [[Media:cola_shared_editing_statespace_divergence_by_more_than_one_op.png|Figure 5]]), it becomes once again apparent, that an operational transformation via <tt>coopt(c,s2)</tt> won't suffice to reach consistent document states on client and server sides.<br />
<br />
The server, being in a document state off by more than one diverging operation considering the state on which <tt>c</tt> had been defined, some course of action is needed to transform <tt>c</tt> with respect to all operations, that have already been applied on the server state, i.e. regarding not only <tt>s2</tt>, but also <tt>s1</tt>.<br />
<br />
''obtaining an intention-preserving instance of operation <tt>c</tt> for application on state <tt>(0,2)</tt>''<br />
<pre><br />
coopt(c,s1)&rarr;(c',s1'); //use c' for transformation against s2<br />
&rArr; coopt(c',s2)&rarr;(c'',s2'); //c'' is OK for application on state (0,2)<br />
</pre><br />
''different notation for the same procedure''<br />
<pre><br />
applyLeftOfResult(coopt(leftOfResult(coopt(c,s1)&rarr;(c',s1')),s2) &rarr; (c'',s2'));<br />
</pre><br />
[[Media:cola_shared_editing_statespace_divergence_by_more_than_one_op_closure.png|Figure 6]] extends the editing scenario accordingly.<br />
=====the algorithm=====<br />
Having closely inspected an example where operational transformations cannot be utilized directly to resolve conflicting situations, we understand the need for an ''encapsulating'' algorithm, taking care of meeting the proper preconditions for the application of '''<tt>coopt</tt>'''.<br />
<br />
Interpreting the state-space graph in [[Media:cola_shared_editing_statespace_algorithm_client_perspective.png|Figure 7]] as how a client perceives an editing session and the processing of local and incoming operations, leads to the required functionality of the controlling ''concurrency algorithm''. From the client's perspective the server was last known to be in state <tt>(x,y)</tt>. The client state has moved on by <tt>k</tt> locally generated and executed operations since the last server-to-client communication. All <tt>k</tt> messages generated by the client have been communicated to the server, so that the next server-generated message is to originate from one of the states between <tt>(x,y)</tt> and <tt>(x+'''k''',y)</tt>. As demonstrated in the introductory example to this subsection, an incoming operation, originating from a state <tt>(x+'''i''',y)</tt>, where i &isin; {0,..,(k-1)}, could not be directly <tt>coopt</tt>'ed with the most recent client operation '''<tt>k</tt>'''. Instead the received server operation has to be consecutively <tt>coopt</tt>'ed with each operation starting with the one generated by the client on the same state as the server operation originated from, leading up to and including the state of operation <tt>k-1</tt>. That is each succeeding <tt>coopt</tt> is called with the result of the transformed server message from the preceding <tt>coopt</tt> and the respective state's local operation. The last <tt>coopt</tt>, which is '''<tt>coopt(i*, k)</tt>''', where ''i* := indicates properly transformed server message/operation i'', yields the intention-preserving transformed operation <tt>i^(*+1)</tt> applicable on the client state and taking it to state '''<tt>(x+k, y+1)</tt>'''. <br />
<br />
Since the ''cola'' architecture is designed to have the server only differ from the clients in that it serves as central notification instance, the algorithm also applies to the server site.<br />
<br />
<br />
<br />
==Integration into Eclipse Communication Framework==<br />
The '''org.eclipse.ecf.example.collab.editor''' plugin provides a [[Example_Shared_Text_Editor|shared editor]] implementation based on the [[Eclipse_Communication_Framework_Project|Eclipse Communication Framework]]. <br />
<br />
It differs from the ''cola'' approach in that it does not utilize advanced mechanisms, such as ''operational transformations'' and a ''concurrency algorithm'', to ensure consistency in document states at discrete sites while maintaining the effects of every editing operation.<br />
Instead of communicating atomic editing operations to each remote site, where state-specific transformations ensure consistent applicability, the [[Example_Shared_Text_Editor|exemplary shared editor]] sends the entire document content to session participants upon local application of an operation. The incoming document overwrites each receiver's copy. In case of communications ''crossing on the wire'', editing information is lost and document states divert.<br />
<br />
In order to maximize code reuse, ''cola's'' sample implementation, '''org.eclipse.ecf.example.sharededitor.cola''', builds on the prior [[Example_Shared_Text_Editor|shared editor]], modifying and extending its functionality as needed. Thus, once deployed and even though the core communications are handled very differently, setting up and running either editor is very much alike.<br />
<br />
===Take a Sip===<br />
====The Cola Source====<br />
''Cola's'' current incarnation lives in a CVS repository at the [http://osuosl.org/ Oregon State University Open Source Lab]. You can get your hands on the sourcecode via anonymous access.<br />
<pre><br />
==server & repository names==<br />
:pserver:anonymous@ecf1.osuosl.org:/ecf<br />
</pre><br />
<pre><br />
==path within repo==<br />
/applications/org.eclipse.ecf.example.sharededitor.cola<br />
</pre><br />
<br />
====Set it Up & Get it Running====<br />
As for obtaining the rest of the code required to build and run ''cola'', consult the [http://www.eclipse.org/ecf/resources.html ECF development resources page] and get the latest sources. A ''team project set'' is provided to greatly simplify your workspace setup.<br />
<br />
Consult the straightforward [[Example_Shared_Text_Editor|how-to]] on the prior shared editor, selecting the ''cola''-specific menu entries at steps '''5.''' and '''7.''', to set up a ''cola'' editing session.<br />
<br />
''Cola'' is stable and functional apart from some minor restrictions, which are being worked on. Currently the following restrictions apply:<br />
*document sharing is limited to two sites<br />
*both participants have to join, prior to editing<br />
*multi-character operations, such as copy & paste of multiple characters or bulk deletion of such, are yet to be implemented.<br />
<br />
==Resources==<br />
===Meeting Notes=== <br />
*[[Eclipse_Communication_Framework_Project|ECF Conference Calls]]<br />
*[[Monday May 29, 2006]]<br />
<br />
===Papers & Books===<br />
*Beck, K 2005, ''Extreme Programming Explained - Embrace Change'', 2nd Ed., Addison-Wesley, Boston MA (USA), p. 42<br />
*Sun, C & Ellis, C 1998, [http://citeseer.ist.psu.edu/sun98operational.html ''Operational Transformation in Real-Time Group Editors: Issues, Algorithms, and Achievements''], Proceedings of the ACM Conference on Computer-Supported Cooperative Work, Seattle WA (USA), pp. 59-68<br />
*Nichols, D, Curtis, P, Dixon, M & Lamping, J 1995, [http://portal.acm.org/citation.cfm?coll=GUIDE&dl=GUIDE&id=215706 ''High-Latency, low-bandwidth windowing in the Jupiter collaboration system''], Proceedings of the 8th annual ACM symposium on User interface and software technology, Pittsburgh PA (USA), pp. 111-120<br />
<br />
[[Category: Eclipse Communication Framework|Real-Time Shared Editing]]</div>Codesurgeon.gmail.comhttps://wiki.eclipse.org/index.php?title=ECF_Conference_Call_11.6.2006&diff=16223ECF Conference Call 11.6.20062006-11-06T20:34:20Z<p>Codesurgeon.gmail.com: /* Attendees */</p>
<hr />
<div>==Attendees==<br />
Scott Lewis, Erkki Lindpere, Roland N. Fru, Mustafa K. Isik, Pierre-Henry Perret<br />
<br />
==Agenda==<br />
<br />
===Status of API Refactoring for 0.9.3===<br />
<br />
===UI and application work===<br />
*Proposals for ''ECF collab application'' update<br />
**IRC client<br />
**XMPP chat functionality<br />
**work on UI to be more accessible<br />
<br />
===Any other business/issues===<br />
*Roland has been elected as committer to ECF. Yay!</div>Codesurgeon.gmail.comhttps://wiki.eclipse.org/index.php?title=ECF_Conference_Call_11.6.2006&diff=16222ECF Conference Call 11.6.20062006-11-06T20:33:23Z<p>Codesurgeon.gmail.com: /* Any other business/issues */</p>
<hr />
<div>==Attendees==<br />
Scott Lewis, Erkki Lindpere, Roland N. Fru, Mustafa K. Isik<br />
<br />
==Agenda==<br />
<br />
===Status of API Refactoring for 0.9.3===<br />
<br />
===UI and application work===<br />
*Proposals for ''ECF collab application'' update<br />
**IRC client<br />
**XMPP chat functionality<br />
**work on UI to be more accessible<br />
<br />
===Any other business/issues===<br />
*Roland has been elected as committer to ECF. Yay!</div>Codesurgeon.gmail.comhttps://wiki.eclipse.org/index.php?title=ECF_Conference_Call_11.6.2006&diff=16221ECF Conference Call 11.6.20062006-11-06T20:31:26Z<p>Codesurgeon.gmail.com: /* Attendees */</p>
<hr />
<div>==Attendees==<br />
Scott Lewis, Erkki Lindpere, Roland N. Fru, Mustafa K. Isik<br />
<br />
==Agenda==<br />
<br />
===Status of API Refactoring for 0.9.3===<br />
<br />
===UI and application work===<br />
*Proposals for ''ECF collab application'' update<br />
**IRC client<br />
**XMPP chat functionality<br />
**work on UI to be more accessible<br />
<br />
===Any other business/issues===</div>Codesurgeon.gmail.comhttps://wiki.eclipse.org/index.php?title=ECF_Conference_Call_11.6.2006&diff=16220ECF Conference Call 11.6.20062006-11-06T20:30:16Z<p>Codesurgeon.gmail.com: /* UI and application work */</p>
<hr />
<div>==Attendees==<br />
Scott Lewis<br />
<br />
==Agenda==<br />
<br />
===Status of API Refactoring for 0.9.3===<br />
<br />
===UI and application work===<br />
*Proposals for ''ECF collab application'' update<br />
**IRC client<br />
**XMPP chat functionality<br />
**work on UI to be more accessible<br />
<br />
===Any other business/issues===</div>Codesurgeon.gmail.comhttps://wiki.eclipse.org/index.php?title=ECF_Application_Refactoring&diff=14005ECF Application Refactoring2006-10-17T14:24:44Z<p>Codesurgeon.gmail.com: mentioned arrangement of plugins in perspectives</p>
<hr />
<div>==Motivation==<br />
The [[Eclipse Communication Framework|Eclipse Communication Framework Project]] team's primary goal is clearly identified as providing an easy-to-use, high quality, consistent, and versatile communications API to the ''Eclipse Platform''. <br />
<br />
In order to better convey the features that ECF has to offer and more effectively generate initial interest in the developer audience, exemplary applications, representing rather tangible incarnations of the opportunities ECF enables, will be created to serve as fully functional showcases of ECF technologies.<br />
<br />
==Existing Items to be Rewritten/Refactored==<br />
===Example Collab Application===<br />
The org.eclipse.ecf.example.collab plugin needs to undergo major refactoring work to extract common components and individual <tt>WorkbenchPart</tt>s so that they can be installed separately or in bundles (similar to how users of Eclipse that just wants the JDT can get the platform+JDT binary without having to install the PDE) and used in [[Application Refactoring#Lightweight RCP Applications|RCP applications]].<br />
<br />
Furthermore, the ''Collab Application'' should offer different sets of plugins, semantically suitable for combination, arranged in distinct workbench perspectives.<br />
<br />
Bug [https://bugs.eclipse.org/bugs/show_bug.cgi?id=160633 #160633] is tracking this work.<br />
<br />
====Suggested initial set of features====<br />
* Discovery of ECF generic, xmpp servers.<br />
* Client runs ECF generic server (user decided)<br />
* XMPP buddy list. Combine Hyperbola and ECF buddy list features<br />
* IRC, XMPP, ECF generic chat<br />
* Bulletin Board API<br />
* File Transfer<br />
* XMPP Group chat<br />
* UI Features for presence, IM, text chat.<br />
** See bugs [https://bugs.eclipse.org/bugs/show_bug.cgi?id=110896 #110896], [https://bugs.eclipse.org/bugs/show_bug.cgi?id=110894 #110894], [https://bugs.eclipse.org/bugs/show_bug.cgi?id=106562 #106562], and [https://bugs.eclipse.org/bugs/show_bug.cgi?id=112599 #112599]<br />
* Open Browser Links.<br />
** See bug [https://bugs.eclipse.org/bugs/show_bug.cgi?id=148874 #148874]<br />
* Text input/output font control<br />
* URL Co-browsing<br />
* Shared Whiteboard<br />
* Event recording and playback<br />
* <Please add more here><br />
<br />
====Suggested package names====<br />
* org.eclipse.ecf.ui<br />
** ECF generic functionalities, common connect dialog<br />
* org.eclipse.ecf.ui.im<br />
** XMPP, IRC, chatting/instant messaging-related<br />
* org.eclipse.ecf.ui.datashare<br />
** shared editor, whiteboard, shared code, file transfer, bulletin board<br />
* org.eclipse.ecf.ui.services<br />
** remote services, publishing subscription, discovery<br />
* <Please feel free to add more or change the names since nothing is yet set in stone.><br />
<br />
==Planned Items==<br />
===Lightweight RCP Applications===<br />
In addition to the already existing, workbench-centric and fairly complete ''Example Collab Application'', a new series of RCP-based applications are planned. The reasoning behind this new set of standalone exemplary implementations is manifold:<br />
*less overwhelming experience to support wider adoption and improve on ''reluctance to try'' threshold<br />
*increased focus on a small set of features to better present them<br />
*clearer definition of target audience and application domain to increase user/developer interest<br />
<br />
Given the existing ECF functionality and desire for the first venture into RCP example application land being of broad appeal, a multi-protocol ECF instant messenger seems quite feasible.<br />
<br />
[More info on the IM client is to follow during the course of the 3rd October week ..., please feel free to add suggestions of your own.]</div>Codesurgeon.gmail.comhttps://wiki.eclipse.org/index.php?title=Eclipse_Communication_Framework_Project&diff=14003Eclipse Communication Framework Project2006-10-17T13:40:25Z<p>Codesurgeon.gmail.com: plural to singular</p>
<hr />
<div>[http://www.eclipse.org/ecf ECF Project Home Page]<br><br />
[http://www.eclipse.org/ecf/downloads.php ECF downloads]<br/><br />
[http://www.eclipse.org/ecf/dev_resources.php ECF Dev Resources (CVS access, newsgroup/mailing list access, etc)]<br/><br />
[http://dev.eclipse.org/mhonarc/lists/ecf-dev/maillist.html ecf-dev@eclipse.org mailing list archive]<br />
<br />
==ECF at Eclipse Summit Europe 2006==<br />
Checkout these guys. They look happy to be working on Eclipse and ECF, no?<br />
[[Image:Eclipsesummiteurope2006.JPG]]<br />
<br />
Also...see the [http://www.eclipsecon.org/summiteurope2006/index.php?page=detail/&id=35 ECF presentation] given at the [http://www.eclipsecon.org/summiteurope2006 Eclipse Summit Europe 2006]<br />
<br />
==ECF Team Meetings==<br />
<br />
ECF has bi-weekly conference calls<br />
<br />
<b>International: 613 287 8000<br><br />
Toll free: 866 362 7064<br><br />
Participant passcode: 892048#<br></b><br />
<br />
<B>[http://www.timeanddate.com/worldclock/fixedtime.html?month=10&day=16&year=2006&hour=12&min=0&sec=0&p1=221 Next Meeting: Monday, Mon Oct 16 at 1200 Pacific, (1900 UTC)]</b><br />
<b>[[ECF Refactoring|SEE PREPARATION NOTES PRIOR TO NEXT CONFERENCE CALL: ECF Refactoring]]</b><br />
<br />
ECF also has ongoing public and private chat groups. Please join!<br />
<br />
IRC (public): <b>irc.freenode.net</b> channel: <b>#eclipse-ecf</b> ECF URL <b>[irc://irc.freenode.net/#eclipse-ecf irc://<user>@irc.freenode.net/#eclipse-ecf]</b><br><br />
XMPP (private): <b><user>@ecf.eclipse.org</b> multi-user chat: <b>ecf</b><br><br />
ECF Generic (public): <b>ecftcp://ecf.eclipse.org:3282/server</b><br />
<br />
====Notes from Previous Meetings====<br />
<br />
[[Conference Call 10.2.2006|Notes from Most Recent Meeting (Mon Oct 2, 2006)]]<br />
<br />
[[Notes from Previous Meetings|Notes from Previous Meetings]]<br />
<br />
==Major Sub-Projects for 2006==<br />
<br />
===[[API Refactoring|ECF API Refactoring Efforts]]===<br />
===[[Application Refactoring|ECF Application Refactoring Efforts]]===<br />
<br />
===[[ECF SOC Projects|Google Summer of Code Projects]]===<br />
===[[Documentation|Documentation: Intro Docs/Examples, Tutorials, Screencasts]]===<br />
===[[Corona Project]]===<br />
===[[DSDP Project]]===<br />
===[[Shared Editing]]===<br />
===[[VOIP|VOIP/Asterisk/Jingle/Call API]]===<br />
===[[JXTA provider for ECF]]===<br />
===[[Enhanced Publish and Subscribe Support]]===<br />
===[[ECF Servers|ECF Servers]]===<br />
===[[Application Sharing|Application Sharing]]===<br />
===[[ECF for eRCP|ECF for eRCP]]===<br />
===[[Multi-User Sudoku]]===<br />
===[[Remote OSGI Services]]===<br />
===[[BB Provider(s)]]===<br />
===[[OLSR provider for ECF]]===</div>Codesurgeon.gmail.comhttps://wiki.eclipse.org/index.php?title=ECF_Application_Refactoring&diff=13980ECF Application Refactoring2006-10-17T00:26:23Z<p>Codesurgeon.gmail.com: introduced notion of RCP example apps</p>
<hr />
<div>==Application Refactorings and Rewrites==<br />
===Motivation===<br />
The Eclipse Communication Framework team's primary goal is clearly identified as providing an easy-to-use, high quality, consistent and versatile communications API to the ''Eclipse Platform''. <br />
<br />
In order to better convey an idea of the features ECF offers and more effectively generate initial interest in a broad developer audience, exemplary applications, representing rather tangible incarnations of the opportunities ECF enables, are to serve as fully functional showcases.<br />
<br />
===Lightweight RCP Applications===<br />
In addition to the already existing, workbench-centric and fairly complete ''Example Collab Application'', a new series of RCP-based applications are planned. The reasoning behind this new set of standalone exemplary implementations is manifold:<br />
*less overwhelming experience to support wider adoption and improve on ''reluctance to try'' threshold<br />
*increased focus on small set of features to better present those<br />
*clearer definition of target audience and application domain to increase user/developer interest<br />
<br />
Given the existing ECF functionality and desire for the first venture into RCP example application land being of broad appeal, a multi-protocol ECF instant messenger seems quite feasible. <br />
<br />
[More info on the IM client is to follow during the course of the 3rd October week ..., please feel free to add suggestions of your own.]<br />
<br />
===Example Collab Application===<br />
Refactor and rewrite org.eclipse.ecf.example.collab plugin. Also need to create RCP app from new<br />
set of top-level plugins.<br />
See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=160633<br />
<br />
Suggested Initial Set of Features:<br />
<br />
* Discovery of ECF generic, xmpp servers.<br />
* Client runs ECF generic server (user decided)<br />
* XMPP buddy list. Combine Hyperbola and ECF buddy list features<br />
* IRC, XMPP, ECF generic chat<br />
* Bulletin Board API<br />
* File Transfer<br />
* XMPP Group chat<br />
* UI Features for presence, IM, text chat. See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=110896 and https://bugs.eclipse.org/bugs/show_bug.cgi?id=110894 and https://bugs.eclipse.org/bugs/show_bug.cgi?id=106562 and https://bugs.eclipse.org/bugs/show_bug.cgi?id=112599<br />
* Open Browser Links. See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=148874<br />
* Text input/output font control<br />
* URL Co-browsing<br />
* Shared Whiteboard<br />
* Event recording and playback<br />
* <Please add more here></div>Codesurgeon.gmail.comhttps://wiki.eclipse.org/index.php?title=ECF_Application_Refactoring&diff=13979ECF Application Refactoring2006-10-16T23:18:42Z<p>Codesurgeon.gmail.com: introduced motivation section</p>
<hr />
<div>==Application Refactorings and Rewrites==<br />
===Motivation===<br />
The Eclipse Communication Framework team's primary goal is clearly identified as providing an easy-to-use, high quality, consistent and versatile communications API to the ''Eclipse Platform''. <br />
<br />
In order to better convey an idea of the features ECF offers and more effectively generate initial interest in a broad developer audience, exemplary applications, representing rather tangible incarnations of the opportunities ECF enables, are to serve as fully functional showcases.<br />
<br />
===Example Collab Application===<br />
Refactor and rewrite org.eclipse.ecf.example.collab plugin. Also need to create RCP app from new<br />
set of top-level plugins.<br />
See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=160633<br />
<br />
Suggested Initial Set of Features:<br />
<br />
* Discovery of ECF generic, xmpp servers.<br />
* Client runs ECF generic server (user decided)<br />
* XMPP buddy list. Combine Hyperbola and ECF buddy list features<br />
* IRC, XMPP, ECF generic chat<br />
* Bulletin Board API<br />
* File Transfer<br />
* XMPP Group chat<br />
* UI Features for presence, IM, text chat. See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=110896 and https://bugs.eclipse.org/bugs/show_bug.cgi?id=110894 and https://bugs.eclipse.org/bugs/show_bug.cgi?id=106562 and https://bugs.eclipse.org/bugs/show_bug.cgi?id=112599<br />
* Open Browser Links. See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=148874<br />
* Text input/output font control<br />
* URL Co-browsing<br />
* Shared Whiteboard<br />
* Event recording and playback<br />
* <Please add more here></div>Codesurgeon.gmail.comhttps://wiki.eclipse.org/index.php?title=ECF_Application_Refactoring&diff=13978ECF Application Refactoring2006-10-16T23:00:56Z<p>Codesurgeon.gmail.com: initial copy of info material on intended application refactorings from former ECF refactorings general page</p>
<hr />
<div>==Application Refactorings and Rewrites==<br />
<br />
===Example Collab Application===<br />
Refactor and rewrite org.eclipse.ecf.example.collab plugin. Also need to create RCP app from new<br />
set of top-level plugins.<br />
See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=160633<br />
<br />
Suggested Initial Set of Features:<br />
<br />
* Discovery of ECF generic, xmpp servers.<br />
* Client runs ECF generic server (user decided)<br />
* XMPP buddy list. Combine Hyperbola and ECF buddy list features<br />
* IRC, XMPP, ECF generic chat<br />
* Bulletin Board API<br />
* File Transfer<br />
* XMPP Group chat<br />
* UI Features for presence, IM, text chat. See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=110896 and https://bugs.eclipse.org/bugs/show_bug.cgi?id=110894 and https://bugs.eclipse.org/bugs/show_bug.cgi?id=106562 and https://bugs.eclipse.org/bugs/show_bug.cgi?id=112599<br />
* Open Browser Links. See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=148874<br />
* Text input/output font control<br />
* URL Co-browsing<br />
* Shared Whiteboard<br />
* Event recording and playback<br />
* <Please add more here></div>Codesurgeon.gmail.comhttps://wiki.eclipse.org/index.php?title=ECF_API_Refactoring&diff=13977ECF API Refactoring2006-10-16T22:58:38Z<p>Codesurgeon.gmail.com: removed section on Application refactoring, since that is to get a page of its own</p>
<hr />
<div>Prior to 1.0, ECF will be going through a concerted API and exemplary app refactoring effort. See below for list of desired refactorings and current state<br />
<br />
==API Refactorings==<br />
<br />
===Split org.eclipse.ecf Core Plugin into 2 or 3 Plugins--LARGE===<br />
Refactor org.eclipse.ecf plugin into 2 or 3 plugins. This is a large refactoring effort.<br />
See discussion thread on mailing list: http://dev.eclipse.org/mhonarc/lists/ecf-dev/msg00399.html<br />
<br />
'''Status''': Not Done<br />
===Add Bulletin Board API to ECF Plugins and Features--LARGE===<br />
Add Bulletin Board API. Remove EE 1.5 dependencies<br />
See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=150756<br />
<br />
'''Status''': Not Done<br />
<br />
===Create filetransfer plugin, remove fileshare plugin===<br />
<br />
Remove org.eclipse.ecf.fileshare API packages and classes. Create a new plugin: org.eclipse.ecf.filetransfer.<br />
<br />
==='Low-end' Execution Environment Support===<br />
<br />
See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=149024<br />
<br />
'''Problem''': Dependency on javax.security.auth.callback.* classes. These classes are not available in Framework 1.1 (they are part of the JAAS classes that are optional for F1.1)<br />
<br />
Removed ECF core and all provider references to classes<br />
<br />
javax.security.auth.callback.Callback;<br />
javax.security.auth.callback.CallbackHandler;<br />
javax.security.auth.callback.NameCallback;<br />
javax.security.auth.callback.UnsupportedCallbackException;<br />
<br />
'''Status: DONE'''<br />
<br />
'''Explanation''': Added new classes and changed existing references to above classes to classes in ECF org.eclipse.ecf.core.security package:<br />
<br />
org.eclipse.ecf.core.security.Callback;<br />
org.eclipse.ecf.core.security.CallbackHandler;<br />
org.eclipse.ecf.core.security.NameCallback;<br />
org.eclipse.ecf.core.security.UnsupportedCallbackException;<br />
<br />
===Add 'removeListener' methods===<br />
<br />
Add removeListener methods in IChatRoomContainer (and in IPresenceContainer). Also check<br />
other listener add and check for availability of remove methods.<br />
See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=160968<br />
<br />
'''Status''': Not Done<br />
<br />
===Streamline ClientSOContainer===<br />
Streamline handling of creating/passing in connect data for new kind of authentication. <br />
See : https://bugs.eclipse.org/bugs/show_bug.cgi?id=150398<br />
<br />
'''Status''': Not Done<br />
<br />
===Move IInvitationListener===<br />
Move (in presence API) access to IInvitationListener to IChatRoomManager rather than IPresenceContainer. <br />
See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=160137<br />
<br />
'''Status''': Not Done<br />
<br />
===Introduce Convention for Container Adapters===<br />
Change all occurrences of I<whatever>Container that are intended to be used as adapters off of IContainer<br />
(via IContainer.getAdapter(I<whatever>Container) to have the following naming convention:<br />
<br />
Was: I<whatever>Container<br />
Will be: I<whatever>ContainerAdapter<br />
<br />
This way, it should be more obvious which interface in a given API plugin is the <br />
container adapter that should be use for the call to IContainer.getAdapter<br />
<br />
'''Status''': Not Done<br />
<br />
===Assure JRE1.4 as EE for All Core Plug-ins===<br />
See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=160805<br />
<br />
<div style="border: 2px solid #8E87EB; padding: 6px;">This isn't necessarily correct as not all plug-ins should be J2SE-1.4 compliant (this is an awkward case since the issue is over a provider's library). Per the discussions on the dev-list, a provider should be allowed to be whatever EE it wants. I have renamed the header as "All Core Plug-ins" instead of "All Plugins". ''--Remy Suen''</div><br />
<div style="border: 2px solid #8E87EB; padding: 6px;">Reading it over, I guess my statement above makes the bug I filed invalid since if a provider plug-in can be whatever EE is necessary, then there is no need to change the Smack library's compiler compliance down to 1.4. I guess the point here is that plug-ins should be consistent in their MANIFEST.MF and compiler settings. Since the Smack library can run on J2SE-1.4 and does not use 5.0 features (generics, foreach, etc.), then the entire project's settings should be set to J2SE-1.4. If it were to need J2SE-1.5, then both the MANIFEST.MF EE and the compiler should be set as such. Inconsistent settings creates confusion for everyone. ''--Remy Suen''</div></div>Codesurgeon.gmail.comhttps://wiki.eclipse.org/index.php?title=Eclipse_Communication_Framework_Project&diff=13976Eclipse Communication Framework Project2006-10-16T22:57:10Z<p>Codesurgeon.gmail.com: updated links to refactoring efforts to better resemble our, i.e. Scott, Roland & Mustafa's, decision to identify two distinct categories of work</p>
<hr />
<div>[http://www.eclipse.org/ecf ECF Project Home Page]<br><br />
[http://www.eclipse.org/ecf/downloads.php ECF downloads]<br/><br />
[http://www.eclipse.org/ecf/dev_resources.php ECF Dev Resources (CVS access, newsgroup/mailing list access, etc)]<br/><br />
[http://dev.eclipse.org/mhonarc/lists/ecf-dev/maillist.html ecf-dev@eclipse.org mailing list archive]<br />
<br />
==ECF at Eclipse Summit Europe 2006==<br />
Checkout these guys. They look happy to be working on Eclipse and ECF, no?<br />
[[Image:Eclipsesummiteurope2006.JPG]]<br />
<br />
Also...see the [http://www.eclipsecon.org/summiteurope2006/index.php?page=detail/&id=35 ECF presentation] given at the [http://www.eclipsecon.org/summiteurope2006 Eclipse Summit Europe 2006]<br />
<br />
==ECF Team Meetings==<br />
<br />
ECF has bi-weekly conference calls<br />
<br />
<b>International: 613 287 8000<br><br />
Toll free: 866 362 7064<br><br />
Participant passcode: 892048#<br></b><br />
<br />
<B>[http://www.timeanddate.com/worldclock/fixedtime.html?month=10&day=16&year=2006&hour=12&min=0&sec=0&p1=221 Next Meeting: Monday, Mon Oct 16 at 1200 Pacific, (1900 UTC)]</b><br />
<b>[[ECF Refactoring|SEE PREPARATION NOTES PRIOR TO NEXT CONFERENCE CALL: ECF Refactoring]]</b><br />
<br />
ECF also has ongoing public and private chat groups. Please join!<br />
<br />
IRC (public): <b>irc.freenode.net</b> channel: <b>#eclipse-ecf</b> ECF URL <b>[irc://irc.freenode.net/#eclipse-ecf irc://<user>@irc.freenode.net/#eclipse-ecf]</b><br><br />
XMPP (private): <b><user>@ecf.eclipse.org</b> multi-user chat: <b>ecf</b><br><br />
ECF Generic (public): <b>ecftcp://ecf.eclipse.org:3282/server</b><br />
<br />
====Notes from Previous Meetings====<br />
<br />
[[Conference Call 10.2.2006|Notes from Most Recent Meeting (Mon Oct 2, 2006)]]<br />
<br />
[[Notes from Previous Meetings|Notes from Previous Meetings]]<br />
<br />
==Major Sub-Projects for 2006==<br />
<br />
===[[API Refactoring|ECF API Refactoring Efforts]]===<br />
===[[Application Refactoring|ECF Applications Refactoring Efforts]]===<br />
===[[ECF SOC Projects|Google Summer of Code Projects]]===<br />
===[[Documentation|Documentation: Intro Docs/Examples, Tutorials, Screencasts]]===<br />
===[[Corona Project]]===<br />
===[[DSDP Project]]===<br />
===[[Shared Editing]]===<br />
===[[VOIP|VOIP/Asterisk/Jingle/Call API]]===<br />
===[[JXTA provider for ECF]]===<br />
===[[Enhanced Publish and Subscribe Support]]===<br />
===[[ECF Servers|ECF Servers]]===<br />
===[[Application Sharing|Application Sharing]]===<br />
===[[ECF for eRCP|ECF for eRCP]]===<br />
===[[Multi-User Sudoku]]===<br />
===[[Remote OSGI Services]]===<br />
===[[BB Provider(s)]]===<br />
===[[OLSR provider for ECF]]===</div>Codesurgeon.gmail.comhttps://wiki.eclipse.org/index.php?title=ECF_API_Refactoring&diff=13974ECF API Refactoring2006-10-16T22:49:57Z<p>Codesurgeon.gmail.com: ECF Refactoring moved to API Refactoring</p>
<hr />
<div>Prior to 1.0, ECF will be going through a concerted API and exemplary app refactoring effort. See below for list of desired refactorings and current state<br />
<br />
==API Refactorings==<br />
<br />
===Split org.eclipse.ecf Core Plugin into 2 or 3 Plugins--LARGE===<br />
Refactor org.eclipse.ecf plugin into 2 or 3 plugins. This is a large refactoring effort.<br />
See discussion thread on mailing list: http://dev.eclipse.org/mhonarc/lists/ecf-dev/msg00399.html<br />
<br />
'''Status''': Not Done<br />
===Add Bulletin Board API to ECF Plugins and Features--LARGE===<br />
Add Bulletin Board API. Remove EE 1.5 dependencies<br />
See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=150756<br />
<br />
'''Status''': Not Done<br />
<br />
===Create filetransfer plugin, remove fileshare plugin===<br />
<br />
Remove org.eclipse.ecf.fileshare API packages and classes. Create a new plugin: org.eclipse.ecf.filetransfer.<br />
<br />
==='Low-end' Execution Environment Support===<br />
<br />
See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=149024<br />
<br />
'''Problem''': Dependency on javax.security.auth.callback.* classes. These classes are not available in Framework 1.1 (they are part of the JAAS classes that are optional for F1.1)<br />
<br />
Removed ECF core and all provider references to classes<br />
<br />
javax.security.auth.callback.Callback;<br />
javax.security.auth.callback.CallbackHandler;<br />
javax.security.auth.callback.NameCallback;<br />
javax.security.auth.callback.UnsupportedCallbackException;<br />
<br />
'''Status: DONE'''<br />
<br />
'''Explanation''': Added new classes and changed existing references to above classes to classes in ECF org.eclipse.ecf.core.security package:<br />
<br />
org.eclipse.ecf.core.security.Callback;<br />
org.eclipse.ecf.core.security.CallbackHandler;<br />
org.eclipse.ecf.core.security.NameCallback;<br />
org.eclipse.ecf.core.security.UnsupportedCallbackException;<br />
<br />
===Add 'removeListener' methods===<br />
<br />
Add removeListener methods in IChatRoomContainer (and in IPresenceContainer). Also check<br />
other listener add and check for availability of remove methods.<br />
See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=160968<br />
<br />
'''Status''': Not Done<br />
<br />
===Streamline ClientSOContainer===<br />
Streamline handling of creating/passing in connect data for new kind of authentication. <br />
See : https://bugs.eclipse.org/bugs/show_bug.cgi?id=150398<br />
<br />
'''Status''': Not Done<br />
<br />
===Move IInvitationListener===<br />
Move (in presence API) access to IInvitationListener to IChatRoomManager rather than IPresenceContainer. <br />
See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=160137<br />
<br />
'''Status''': Not Done<br />
<br />
===Introduce Convention for Container Adapters===<br />
Change all occurrences of I<whatever>Container that are intended to be used as adapters off of IContainer<br />
(via IContainer.getAdapter(I<whatever>Container) to have the following naming convention:<br />
<br />
Was: I<whatever>Container<br />
Will be: I<whatever>ContainerAdapter<br />
<br />
This way, it should be more obvious which interface in a given API plugin is the <br />
container adapter that should be use for the call to IContainer.getAdapter<br />
<br />
'''Status''': Not Done<br />
<br />
===Assure JRE1.4 as EE for All Core Plug-ins===<br />
See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=160805<br />
<br />
<div style="border: 2px solid #8E87EB; padding: 6px;">This isn't necessarily correct as not all plug-ins should be J2SE-1.4 compliant (this is an awkward case since the issue is over a provider's library). Per the discussions on the dev-list, a provider should be allowed to be whatever EE it wants. I have renamed the header as "All Core Plug-ins" instead of "All Plugins". ''--Remy Suen''</div><br />
<div style="border: 2px solid #8E87EB; padding: 6px;">Reading it over, I guess my statement above makes the bug I filed invalid since if a provider plug-in can be whatever EE is necessary, then there is no need to change the Smack library's compiler compliance down to 1.4. I guess the point here is that plug-ins should be consistent in their MANIFEST.MF and compiler settings. Since the Smack library can run on J2SE-1.4 and does not use 5.0 features (generics, foreach, etc.), then the entire project's settings should be set to J2SE-1.4. If it were to need J2SE-1.5, then both the MANIFEST.MF EE and the compiler should be set as such. Inconsistent settings creates confusion for everyone. ''--Remy Suen''</div><br />
<br />
==Application Refactorings and Rewrites==<br />
<br />
===Example Collab Application===<br />
Refactor and rewrite org.eclipse.ecf.example.collab plugin. Also need to create RCP app from new<br />
set of top-level plugins.<br />
See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=160633<br />
<br />
Suggested Initial Set of Features:<br />
<br />
* Discovery of ECF generic, xmpp servers.<br />
* Client runs ECF generic server (user decided)<br />
* XMPP buddy list. Combine Hyperbola and ECF buddy list features<br />
* IRC, XMPP, ECF generic chat<br />
* Bulletin Board API<br />
* File Transfer<br />
* XMPP Group chat<br />
* UI Features for presence, IM, text chat. See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=110896 and https://bugs.eclipse.org/bugs/show_bug.cgi?id=110894 and https://bugs.eclipse.org/bugs/show_bug.cgi?id=106562 and https://bugs.eclipse.org/bugs/show_bug.cgi?id=112599<br />
* Open Browser Links. See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=148874<br />
* Text input/output font control<br />
* URL Co-browsing<br />
* Shared Whiteboard<br />
* Event recording and playback<br />
* <Please add more here></div>Codesurgeon.gmail.comhttps://wiki.eclipse.org/index.php?title=ECF_Refactoring&diff=13975ECF Refactoring2006-10-16T22:49:57Z<p>Codesurgeon.gmail.com: ECF Refactoring moved to API Refactoring: On our conference call on Monday, October 16th, which was attended by Scott, Roland and Mustafa and later Pierre, it was decided to decouple the ECF refactoring efforts to better resemble the two main areas of wor</p>
<hr />
<div>#redirect [[API Refactoring]]</div>Codesurgeon.gmail.comhttps://wiki.eclipse.org/index.php?title=RT_Shared_Editing&diff=11549RT Shared Editing2006-09-22T20:29:38Z<p>Codesurgeon.gmail.com: made advice for connection to repo clearer by dividing up the full access path</p>
<hr />
<div><!-- Introduction --><br />
'''Project Lead''': [http://codesurgeon.blogspot.com/ Mustafa K. Isik]<br />
<br />
'''Mentor(s)''': Scott Lewis, Ken Gilmer<br />
<br />
==Motivation==<br />
The ''RT Shared Editor'', which I'll dub ''Cola'' ('''col'''l'''a'''borate) for now, is supposed to be a tool enabling developers to reap the benefits of pair programming within the Eclipse IDE.<br />
<br />
The term ''pair programming'' describes an activity in which two developers simultaneously work on a single development machine. <br />
<br />
Even though not new to the development community, ''pair programming'' has witnessed a significant rise in adoption over the last years. One of the main reasons being the inclusion to the set of [http://www.extremeprogramming.org/ eXtreme programming (aka ''XP'')] practices. Thus ''pair programming'' is especially, but certainly not only, popular among developers utilizing the values, principles and practices propagated by the ''XP'' methodology.<br />
<br />
The reasoning behind ''pair programming'', as articulated by software developer, author and ''XP'' figurehead [[RT Shared Editing#Resources|Kent Beck (2005 p.42)]] is manifold and pair programmer's activities are described as<br />
*keep each other focused and on task<br />
*brainstorm refinements to the system<br />
*clarify ideas<br />
*take initiative when their partner is stuck, lowering frustration<br />
*hold each other accountable to the team's practices<br />
<br />
From my own experience I can add, that programming in pairs has proved to be beneficial in<br />
*widening developers' horizons and perspectives on perceiving and tackling problems<br />
*increasing trust in one's own skills and generating awareness for areas requiring improvement<br />
*learning from more advanced developers<br />
**improving through working with less experienced devs, motivating to reflect on the essence of one's own practices<br />
*refining one's own communication skills<br />
<br />
===Current Situation===<br />
Tool-support for ''pair programming'' in [http://www.eclipse.org Eclipse] is pretty much non-existent. Pair programming sessions, as spontaneous as they might be arranged in some teams, usually are set up for longer periods of time, ranging anywhere from an hour to some four or five. Pairs consist of locally available developers.<br />
<br />
===Limitations & Problems===<br />
Geographical limitations do not permit for simple pair programming.<br />
Since individuals are required to sit in front of the same machine, they apparently have to be located at offices close to each other.<br />
Thus software development, not being a regionally bound activity, as proven by the sustained success and advances of open-source software and the nature of many open-source teams, has to be carried out without utilizing effective pair programming in many cases.<br />
<br />
Even when developers are located at the same work site, the effort to get two people set up together in front of a computer (drinks, resources, etc.) proves not to be worth for short programming or reviewing tasks, which sometimes are all that is required. This does not mean that coders do not occasionally sit down for such quick tasks, but from personal experience not as often as it might be beneficial for oneself and/or the code.<br />
<br />
Traditional instant messaging software does not lend itself for code communication among developers. Such software generally proves to be fairly feature-limited and catering to different target audiences. Theoretically it would lend itself for sending back and forth short code snippets at best, practically large-scale adoption of such behaviour has yet to be seen.<br />
<br />
Open-plan offices or group cube farm layouts do not support developers in utilizing pair programming benefits either, quickly degrading the workspace noise-level to that of an airport lobby (by the way, the true problem here would be of course the office layout, but the scope of changing that is unfortunately usually beyond the individual developer).<br />
<br />
Furthermore developers, who usually keep book resources in their personal work environment, end up being stripped of those for half of the time they are pair programming.<br />
<br />
===Resolution===<br />
''Cola'' is supposed to support collaborative work on code from disparate locations, minimizing organizational impact and improving on flexibility issues concerning pair programming.<br />
<br />
Developers are intended to be able to work simultaneously on a single source file, viewing changes made by other contributors in real-time and editing the most up-to-date version of the file at all times.<br />
<br />
The initial incarnation of ''Cola'' is to materialize in the form of an Eclipse IDE plug-in.<br />
<br />
==Consistency Maintenance==<br />
Maintaining consistency among shared data in a distributed real-time editing environment is of prime importance.<br />
<br />
Over the last decade a lot of thought has been dedicated to the research of domain-specific issues in real-time collaborative groupware systems. Chengzheng Sun and Clarence Ellis have authored a [[RT Shared Editing#Resources|paper (Sun & Ellis 1998)]] providing a thorough overview of such. The subsequent discussion of challenges specific to real-time collaborative editing is based on the referenced paper and intended to be self-sustaining in that you will not have to dig into academic research material to understand the challenges at hand.<br />
<!-- [[Image:cola_shared_editing_trivial.png|thumb|150px|right|idealistic editing scenario]] --><br />
[[Media:cola_shared_editing_trivial.png|Figure 1]] shows a somewhat ''idealistic'' scenario where communication lag between several editing sites remains without undesired consequences because operations are generated and executed at all sites in an orderly fashion.<br />
In a ''realistic'' distributed editing scenario, as depicted in [[Media:cola_shared_editing_nontrivial.png|Figure 2]], the need for consistency maintenance becomes apparent.<br />
===Challenges===<br />
====Divergence====<br />
<!-- [[Image:cola_shared_editing_nontrivial.png|thumb|400px|left|exemplary editing scenario]] this does not work! could it be that something is wrong with the eclipsepedia configuration? --><br />
Due to dependencies between operations originating from different editors on a shared document and suffering from propagation lag in a distributed environment, shared data state at different sites can divert from each other. This holds especially true for operations that are not [http://en.wikipedia.org/wiki/Commutative commutative] in execution order.<br />
{|border="1" cellpadding="5" cellspacing="0" align="center"<br />
|+''divergence'' in [[Media:cola_shared_editing_divergence.png|Figure 3]]<br />
|-<br />
! style="background:#efefef;" | site 1<br />
! style="background:#ffdead;" | state<br />
! style="background:#efefef;" | site 2<br />
! style="background:#ffdead;" | state<br />
! style="background:#efefef;" | site 3<br />
! style="background:#ffdead;" | state<br />
|-<br />
|A:''insert('a')''||a||A:''insert('a')''||a||A:''insert('a')''||a<br />
|-<br />
|C:''insert('c')''||'''ac'''||B:''insert('b')''||ab||B:''insert('b')''||ab<br />
|-<br />
|B:''insert('b')''||'''acb'''||C:''insert('c')''||'''abc'''||C:''insert('c')''||'''abc'''<br />
|}<br />
<br />
====Causality-violation====<br />
Each editing user's changes need to be communicated to the other editing sites. Independent from message generation times, notification of changes may arrive out-of-order. The resulting artifact for dependent operations is referred to as ''causality-violation''. The order in which operations A and B in [[Media:cola_shared_editing_nontrivial.png|Figure 2]] arrive at site 3 visualizes a typical case of ''causality-violation''. Operation B is generated at site 2 after the arrival and execution of operation A. The reversed arrival order of both operations at site 3 may result in an undefined operation B at site 3 (e.g. B is supposed to delete an insertion commited by A).<br />
Depending on the underlying communications protocol even the in-order arrival of editing operations originating from the same site [[Media:cola_shared_editing_causality.png|might not be guaranteed]].<br />
<br />
====Intention-violation====<br />
''Intention-violation'' is different from ''causality-violation'' in that it refers to the problems that arise when executing an operation on a document state altered by operations not having been executed at the operation's generation site.<br />
<br />
Operation C in [[Media:cola_shared_editing_nontrivial.png|Figure 2]] is defined/generated at site 3 on a document state neither affected by operation A nor B. Upon arrival and execution at sites 2 and 3 the respective document states have already been changed by operations A and B and can cause operation C to commit an unintended and undesired change.<br />
<br />
In contrast to the ''divergence''-problem, ''intention-violation'' cannot be resolved by a simple ''serialization protocol''.<br />
<br />
===Resolution Approach===<br />
====Look at the Sky & Spot JUPITER====<br />
A closer inspection of a paper titled "High-Latency, Low-Bandwidth Windowing in the Jupiter Collaboration System" [[RT Shared Editing#Resources| (Nichols ''et al'' 1995)]] reveals a very interesting approach to solving distributed-state synchronization problems in systems with more than two participating sites. <br />
<br />
Even though functionality-wise the more advanced approaches described in [[RT Shared Editing#Resources|(Sun & Ellis 1998)]] also represent solutions to the challenges in realizing ''Cola'', [[RT Shared Editing#Resources| (Nichols ''et al'' 1995)]] makes assumptions perfectly feasible for ''Cola'''s case that (in relative terms) greatly simplify the required concurrency-control algorithm.<br />
<br />
====Client-Server Communications====<br />
Much of the complexity of for instance the ''GROVE'' and ''REDUCE'' collaboration models stem from the fact, that they are designed for handling arbitrary communication-paths between each editing site. The ''JUPITER'' collaboration system on the other hand is [[Media:cola_client_server.png|designed around a central server]]. Utilizing the resulting communications topology, conflicting messages are resolved on the level of 2-way messaging between ''specific client - central server'' as opposed to [[Media:cola_n_way.png|n-way communications]]. <br />
<br />
Concerning ''causality-violation'', communications being effectively limited to 2-way / routed through the server document state, out-of-order arrival of messages adhering to a causal order, such as deletions referring to prior insertions, is prohibited. The central ordering instance, the server editing site, ensures, that all sites are updated in the right causal order.<br />
<br />
====Network Protocol====<br />
Considering [[Media:cola_shared_editing_causality.png|operations originating from the same site]], ''causality-violation'' of this specific type or more general reversed messaging, can be prohibited by using a ''network protocol'' not permitting for out-of-order communication of operations to the receiving site (either client or server). <br />
''Cola'''s network protocol will be chosen with respect to satisfaction of this property.<br />
<br />
====Optimistic Change Application====<br />
Responsiveness and immediate user feedback are important and expected features in an editor, therefore user operations are applied immediately to the local document state without awaiting server approval or undergoing any modifications.<br />
<br />
====Conflict Resolution via Operational Transformations====<br />
Even with the client-server topology in place and a 2-way messaging protocol ordering communications, preventing the out-of-order arrival of messages causing causality-violation, intention-violation can still occur. <br />
<br />
This becomes apparent when considering, that causality-violation is due to remote messages either from different sites or originating from a single site ''crossing on the wire'' on their way to the unaltered, i.e. consistent in document state concerning all prior operations, recipient. Ensuring the ordered arrival and execution of operations at the receiver site suffices to maintain consistency in document state.<br />
<br />
''Intention-violation'' on the other hand describes problems that occur due to operations being intended for execution on a certain document state, which is not available upon their arrival at the receiver. Locally generated and executed operations have altered the receiving site's document state during the transmission of remote operations. In this scenario, best described as mutually directed messages crossing on the wire, the same problem applies the other way around when exchanging sender and receiver labels on the sites.<br />
<br />
Application of operations on a document state different from the one they'd been intended for, bears the danger of intention violation, ranging from insertions at wrong places to deletion of wrong sections.<br />
Dropping and rolling back operations, in such a highly interactive application domain, is not an option, especially since local operations are executed immediately. <br />
<br />
Therefore ''intention-preserving transformations'' of such operations, i.e. ''operational transformations'', are key to ''Cola's'' resolution approach.<br />
<br />
<tt><br />
'''basic 2-way communication is of the form'''<br />
*client generates operation<br />
*client executes operation locally<br />
*client notifies server of operation<br />
*server receives operation<br />
*''in case of conflict:'' server '''transforms''' operation<br />
*server executes operation locally<br />
*server notifies all other clients of operation<br />
''for every receiving client''<br />
*client receives operation<br />
*''in case of conflict:'' client '''transforms''' operation<br />
*client executes operation locally<br />
</tt><br />
<br />
<br />
Presenting ''operational transformations'' as a means for conflict resolution, several immediate concerns arise<br />
#what ''are'' cola's operations on which to perform transformations<br />
#how do conflicting scenarios look like<br />
#what do operational transformations ''look like'' and<br />
#how are ''conflicts in document state'' to be ''detected'' in order to resolve them via transformations on operations?<br />
<br />
''Cola'' models all editing operations on documents as atomic ''deletions'' and ''insertions'' of single characters. Editing operations on more than a single char are broken down to atomic operations, as listed below.<br />
<pre><br />
&rarr; del(position)<br />
&rarr; del(from_position, to_position):=<br />
for(int i = from_position; i <= to_position; i++){<br />
del(i); <br />
}<br />
&rarr; ins(position, char)<br />
&rarr; ins(from_position, string):=<br />
for(int i = 0; i < string.length; i++){<br />
ins(from_position + i, string[i]);<br />
}<br />
</pre><br />
<br />
<br />
An example serves best to illustrate the features demanded of ''operational transformations''.<br />
<br />
{|border="1" cellpadding="3" cellspacing="0" align="center"<br />
|+''conflicting insertions''<br />
|-<br />
! style="background:#efefef;" | remote op.<br />
! style="background:#efefef;" | local op.<br />
! style="background:#ff8c00;" | state @ client 1<br />
! style="background:#6495ed;" | state @ client 2<br />
! style="background:#efefef;" | local op.<br />
! style="background:#efefef;" | remote op.<br />
|-<br />
| ||<font color=darkorange>ins(2,O)</font>||CRON||CRON||<font color=blue>ins(5,A)</font>|| <br />
|-<br />
|<font color=blue>ins(5,A)</font>|| ||C'''O'''RON||CRON'''A'''|| ||<font color=darkorange>ins(2,O)</font><br />
|-<br />
| || ||CORO<font color=red>'''A'''</font>N||CORON<font color=green>'''A'''</font>|| ||<br />
|}<br />
<br />
The user at site 2 intends to insert an ''A'' after the last ''N''. When the corresponding operation he issued and which was successfully applied to his local document, arrives at site 1 the document state has been altered by the insertion of another character at a lower index, thus shifting all subsequent characters' indeces by one. The untransformed execution of the insertion from site 2 on site 1's document results in intention-violation. The obvious solution in this case would be to increment the insertion op's index by one and executing <tt>ins(6,O)</tt><br />
<br />
Building on the information provided by the knowledge of the document states being one operation apart and knowing which two operations are intended for execution, abstraction and generalization lead to the specific operational transformation for two conflicting insertions. <br />
<br />
With regard to the ''conflicting insertions'' example, and the type of relation defined by transformations on operations, it becomes apparent that the transformation can be precisely described in terms of a function taking two conflicting operations at a time as input parameters and delivering two output operations modified for intention-preserving applicability at their respective destination sites.<br />
<br />
For brevity reasons, I will refer to cola's operational transformation function as '''<tt>coopt</tt>''' function (for '''co'''la '''op'''erational '''t'''ransformation).<br />
<pre><br />
coopt(ins(x, char_1), ins(y, char_2)):=<br />
{(ins(x, char_1), ins(y + 1, char_2)) , for x < y<br />
(ins(x + 1, char_1), ins(y, char_2)) , for x > y<br />
(noop, noop) , for x = y && char_1 == char_2<br />
serverside insertion comes first , for x = y && char_1 != char_2<br />
}<br />
</pre><br />
<br />
Using '''<tt>coopt</tt>''' for resolving the conflict between the insertion operations in our example, yields the same and intention-preserved document state at both sites.<br />
<br />
{|border="1" cellpadding="3" cellspacing="0" align="center"<br />
|+''conflicting insertions resolved via coopt''<br />
|-<br />
! style="background:#efefef;" | remote op.<br />
! style="background:#efefef;" | local op.<br />
! style="background:#ff8c00;" | state @ client 1<br />
! style="background:#6495ed;" | state @ client 2<br />
! style="background:#efefef;" | local op.<br />
! style="background:#efefef;" | remote op.<br />
|-<br />
| ||<font color=darkorange>ins(2,O)</font>||CRON||CRON||<font color=blue>ins(5,A)</font>|| <br />
|-<br />
|'''coopt('''<font color=blue>ins(5,A)</font>''',''' ins(2,O)''')'''<br>&rarr; <font color=blue>ins('''6''',A)</font>|| ||C'''O'''RON||CRON'''A'''|| ||'''coopt('''<font color=darkorange>ins(2,O)</font>''',''' ins(5,A)''')'''<br>&rarr; <font color=darkorange>ins(2,O)</font><br />
|-<br />
| || ||CORON<font color=green>'''A'''</font>||CORON<font color=green>'''A'''</font>|| ||<br />
|}<br />
<br />
Conflicts can also arise for deletions at both sites and deletion and insertion operations executed on the same document state at two different sites.<br />
<br />
{|border="1" cellpadding="3" cellspacing="0" align="center"<br />
|+''conflicting deletions''<br />
|-<br />
! style="background:#efefef;" | remote op.<br />
! style="background:#efefef;" | local op.<br />
! style="background:#ff8c00;" | state @ client 1<br />
! style="background:#6495ed;" | state @ client 2<br />
! style="background:#efefef;" | local op.<br />
! style="background:#efefef;" | remote op.<br />
|-<br />
| ||<font color=darkorange>del(6)</font>||MARIPOSA||MARIPOSA||<font color=blue>del(5)</font>|| <br />
|-<br />
|<font color=blue>del(5)</font>|| ||MARIPSA||MARIOSA|| ||<font color=darkorange>del(6)</font><br />
|-<br />
| || ||MARISA||MARIO<font color=red>'''A'''</font>|| ||<br />
|}<br />
<br />
The specific conflict in the ''conflicting deletions'' table can be resolved by decrementing the index of the <tt>del(6)</tt> operation originating from site 1 by one upon arrival at and prior to execution at site 2.<br />
<br />
As for insertions, '''<tt>coopt</tt>''' handles conflicting deletions in a general way.<br />
<pre><br />
coopt(del(x), del(y):=<br />
{(del(x), del(y - 1) , for x < y<br />
(del(x - 1), del(y) , for x > y<br />
(noop, noop) , for x = y <br />
}<br />
</pre><br />
Transforming remote delete operations defined on document states one operation apart from the local state, results in conflict free convergence.<br />
<br />
{|border="1" cellpadding="3" cellspacing="0" align="center"<br />
|+''conflicting deletions resolved via coopt''<br />
|-<br />
! style="background:#efefef;" | remote op.<br />
! style="background:#efefef;" | local op.<br />
! style="background:#ff8c00;" | state @ client 1<br />
! style="background:#6495ed;" | state @ client 2<br />
! style="background:#efefef;" | local op.<br />
! style="background:#efefef;" | remote op.<br />
|-<br />
| ||<font color=darkorange>del(6)</font>||MARIPOSA||MARIPOSA||<font color=blue>del(5)</font>|| <br />
|-<br />
|'''coopt('''<font color=blue>del(5)</font>''',''' del(6)''')'''<br>&rarr; <font color=blue>del(5)</font>|| ||MARIPSA||MARIOSA|| ||'''coopt('''<font color=darkorange>del(6)</font>''',''' del(5)''')'''<br>&rarr; <font color=darkorange>del('''5''')</font><br />
|-<br />
| || ||MARISA||MARISA|| ||<br />
|}<br />
<br />
''Cola'' provides two more operations, which also need to be handled by '''<tt>coopt</tt>'''. These last operations are intended to improve on the collaborative experience and are of non-editing nature. Both operations are user-specific in that every user's cursor, possibly each in a different color, is replicated among editing sites. This is to make remote user operations more comprehensible for the respective local user. The same applies to the user-specific highlighting of editor contents.<br />
<pre><br />
&rarr; cursor(position, user)<br />
&rarr; highlight(position, user)<br />
&rarr; highlight(from_position, to_position, user):=<br />
for(int i = from_position; i <= to_position; i++){<br />
highlight(i, user); <br />
}<br />
</pre><br />
<br />
====Concurrency Algorithm====<br />
Summarizing the previous section and giving a motivation for the one at hand, ''operational transformations'' are applicable on operations, defined on the same document state at different sites. When reaching their respective destination sites in such scenarios, the remote sites' document state diverges by ''one operation''. The transformation modifies the incoming operation with respect to the operation that has been executed at the receiving site, so that ''intention-preservation'' for the incoming operation is satisfied.<br />
<br />
In cases where the local, receiving document state ''diverges by more than one (locally executed) operation'' compared to the state at a remote site sending an operation, the mechanism of ''operational transformations'' cannot be utilized directly. The previously iterated preconditions for the application of such are not met.<br />
<br />
A ''concurrency algorithm'' takes care of detecting conflicting situations and meeting requirements for resolution via ''operational transformations''.<br />
<br />
[[Media:cola_shared_editing_statespace_simple.png|Figure 4]] features an exemplary graph of the state-space a client and the server editing site roam during a session. The diagram visualizes a scenario where during editing, document states at client and server side diverge by a single operation respectively and get resolved via operational transformations.<br />
<br />
As indicated, the need for a concurrency algorithm arises in part from the non-applicability of operational transformations on document states diverging by more than a single operation, as presented in [[Media:cola_shared_editing_statespace_divergence_by_more_than_one_op.png|Figure 5]]. The graph shows client and server sites diverging as of state <tt>(0,0)</tt>. The client site receives the server message, which it directly transforms via the <tt>coopt</tt>-function and subsequently applies to its document state. Let <tt>c</tt> be the initial client application, and <tt>s1</tt> the first server-site operation. <tt>coopt(c,s1)</tt> results in a 2-tuple <tt>(c',s1')</tt> of which the parameters are characterized by the equation <tt>c &#x2299; s1' = s1 &#x2299; c'</tt> Interpreting the equation, the subsequent application of <tt>s1'</tt> to a document state <tt>c</tt> results in the same state as applying <tt>s1</tt> followed by <tt>c'</tt>. This is by definition the exact thing the operational transformation function <tt>coopt</tt> is to take care of.<br />
The interesting part is when the client receives another message <tt>s2</tt>, having been generated on a document state only incorporating operation <tt>s1</tt>, <tt>s2</tt> cannot be applied to the client state <tt>c &#x2299; s1'</tt> directly. But since the client already contains <tt>s1</tt>, which just had been applied to the client-local state via <tt>s1'</tt> in the previous step, the precondition for conflict-resolution via <tt>coopt</tt>, i.e. divergence by a single operation, is met. <br />
<br />
''The important and central question is what other parameter is supposed to go into <tt>coopt</tt> with <tt>s2</tt>.''<br />
<br />
Considering that the server-state did not contain <tt>c</tt> when generating <tt>s2</tt>, <tt>c</tt> in some form resembles/relates to the deviating operation. With <tt>c'</tt> we are aware of a transformed version of operation <tt>c</tt>, which could be applied to an <tt>s1</tt> document state in an intention-preserving/non-destructive manner. Thus <tt>c'</tt> is to be the other parameter to be respected when transforming operation <tt>s2</tt> for applicability on the client side. [[Media:cola_shared_editing_statespace_divergence_by_more_than_one_op.png|Figure 5]] has concrete operations substituted for <tt>c, s1, and s2</tt>.<br />
<br />
{|border="1" cellpadding="3" cellspacing="0" align="center"<br />
|+''mapping for exemplary operations in Figure 5''<br />
|-<br />
! style="background:#efefef;" | <tt>c</tt><br />
! style="background:#efefef;" | <tt>c'</tt><br />
! style="background:#efefef;" | <tt>c' '</tt><br />
! style="background:#6495ed;" | <tt>s1</tt><br />
! style="background:#6495ed;" | <tt>s1'</tt><br />
! style="background:#ff8c00;" | <tt>s2</tt><br />
! style="background:#ff8c00;" | <tt>s2'</tt><br />
|-<br />
|del(5)||del(5)||del(5)||del(9)||del(8)||del(8)||del(7) <br />
|}<br />
<br />
Assuming that in state <tt>(0,2)</tt> the server receives the client-message originating from state <tt>(0,0)</tt> and communicating the client-operation <tt>c</tt> (i.e. <tt>del(5)</tt> in [[Media:cola_shared_editing_statespace_divergence_by_more_than_one_op.png|Figure 5]]), it becomes once again apparent, that an operational transformation via <tt>coopt(c,s2)</tt> won't suffice to reach consistent document states on client and server sides.<br />
<br />
The server, being in a document state off by more than one diverging operation considering the state on which <tt>c</tt> had been defined, some course of action is needed to transform <tt>c</tt> with respect to all operations, that have already been applied on the server state, i.e. regarding not only <tt>s2</tt>, but also <tt>s1</tt>.<br />
<br />
''obtaining an intention-preserving instance of operation <tt>c</tt> for application on state <tt>(0,2)</tt>''<br />
<pre><br />
coopt(c,s1)&rarr;(c',s1'); //use c' for transformation against s2<br />
&rArr; coopt(c',s2)&rarr;(c'',s2'); //c'' is OK for application on state (0,2)<br />
</pre><br />
''different notation for the same procedure''<br />
<pre><br />
applyLeftOfResult(coopt(leftOfResult(coopt(c,s1)&rarr;(c',s1')),s2) &rarr; (c'',s2'));<br />
</pre><br />
[[Media:cola_shared_editing_statespace_divergence_by_more_than_one_op_closure.png|Figure 6]] extends the editing scenario accordingly.<br />
=====the algorithm=====<br />
Having closely inspected an example where operational transformations cannot be utilized directly to resolve conflicting situations, we understand the need for an ''encapsulating'' algorithm, taking care of meeting the proper preconditions for the application of '''<tt>coopt</tt>'''.<br />
<br />
Interpreting the state-space graph in [[Media:cola_shared_editing_statespace_algorithm_client_perspective.png|Figure 7]] as how a client perceives an editing session and the processing of local and incoming operations, leads to the required functionality of the controlling ''concurrency algorithm''. From the client's perspective the server was last known to be in state <tt>(x,y)</tt>. The client state has moved on by <tt>k</tt> locally generated and executed operations since the last server-to-client communication. All <tt>k</tt> messages generated by the client have been communicated to the server, so that the next server-generated message is to originate from one of the states between <tt>(x,y)</tt> and <tt>(x+'''k''',y)</tt>. As demonstrated in the introductory example to this subsection, an incoming operation, originating from a state <tt>(x+'''i''',y)</tt>, where i &isin; {0,..,(k-1)}, could not be directly <tt>coopt</tt>'ed with the most recent client operation '''<tt>k</tt>'''. Instead the received server operation has to be consecutively <tt>coopt</tt>'ed with each operation starting with the one generated by the client on the same state as the server operation originated from, leading up to and including the state of operation <tt>k-1</tt>. That is each succeeding <tt>coopt</tt> is called with the result of the transformed server message from the preceding <tt>coopt</tt> and the respective state's local operation. The last <tt>coopt</tt>, which is '''<tt>coopt(i*, k)</tt>''', where ''i* := indicates properly transformed server message/operation i'', yields the intention-preserving transformed operation <tt>i^(*+1)</tt> applicable on the client state and taking it to state '''<tt>(x+k, y+1)</tt>'''. <br />
<br />
Since the ''cola'' architecture is designed to have the server only differ from the clients in that it serves as central notification instance, the algorithm also applies to the server site.<br />
<br />
<br />
<br />
==Integration into Eclipse Communication Framework==<br />
The '''org.eclipse.ecf.example.collab.editor''' plugin provides a [[Example_Shared_Text_Editor|shared editor]] implementation based on the [[Eclipse_Communication_Framework_Project|Eclipse Communication Framework]]. <br />
<br />
It differs from the ''cola'' approach in that it does not utilize advanced mechanisms, such as ''operational transformations'' and a ''concurrency algorithm'', to ensure consistency in document states at discrete sites while maintaining the effects of every editing operation.<br />
Instead of communicating atomic editing operations to each remote site, where state-specific transformations ensure consistent applicability, the [[Example_Shared_Text_Editor|exemplary shared editor]] sends the entire document content to session participants upon local application of an operation. The incoming document overwrites each receiver's copy. In case of communications ''crossing on the wire'', editing information is lost and document states divert.<br />
<br />
In order to maximize code reuse, ''cola's'' sample implementation, '''org.eclipse.ecf.example.sharededitor.cola''', builds on the prior [[Example_Shared_Text_Editor|shared editor]], modifying and extending its functionality as needed. Thus, once deployed and even though the core communications are handled very differently, setting up and running either editor is very much alike.<br />
<br />
===Take a Sip===<br />
====The Cola Source====<br />
''Cola's'' current incarnation lives in a CVS repository at the [http://osuosl.org/ Oregon State University Open Source Lab]. You can get your hands on the sourcecode via anonymous access.<br />
<pre><br />
==server & repository names==<br />
:pserver:anonymous@ecf1.osuosl.org:/ecf<br />
</pre><br />
<pre><br />
==path within repo==<br />
/applications/org.eclipse.ecf.example.sharededitor.cola<br />
</pre><br />
<br />
====Set it Up & Get it Running====<br />
As for obtaining the rest of the code required to build and run ''cola'', consult the [http://www.eclipse.org/ecf/resources.html ECF development resources page] and get the latest sources. A ''team project set'' is provided to greatly simplify your workspace setup.<br />
<br />
Consult the straightforward [[Example_Shared_Text_Editor|how-to]] on the prior shared editor, selecting the ''cola''-specific menu entries at steps '''5.''' and '''7.''', to set up a ''cola'' editing session.<br />
<br />
''Cola'' is stable and functional apart from some minor restrictions, which are being worked on. Currently the following restrictions apply:<br />
*document sharing is limited to two sites<br />
*both participants have to join, prior to editing<br />
*multi-character operations, such as copy & paste of multiple characters or bulk deletion of such, are yet to be implemented.<br />
<br />
==Resources==<br />
===Meeting Notes=== <br />
*[[Eclipse_Communication_Framework_Project|ECF Conference Calls]]<br />
*[[Monday May 29, 2006]]<br />
<br />
===Papers & Books===<br />
*Beck, K 2005, ''Extreme Programming Explained - Embrace Change'', 2nd Ed., Addison-Wesley, Boston MA (USA), p. 42<br />
*Sun, C & Ellis, C 1998, [http://citeseer.ist.psu.edu/sun98operational.html ''Operational Transformation in Real-Time Group Editors: Issues, Algorithms, and Achievements''], Proceedings of the ACM Conference on Computer-Supported Cooperative Work, Seattle WA (USA), pp. 59-68<br />
*Nichols, D, Curtis, P, Dixon, M & Lamping, J 1995, [http://portal.acm.org/citation.cfm?coll=GUIDE&dl=GUIDE&id=215706 ''High-Latency, low-bandwidth windowing in the Jupiter collaboration system''], Proceedings of the 8th annual ACM symposium on User interface and software technology, Pittsburgh PA (USA), pp. 111-120</div>Codesurgeon.gmail.comhttps://wiki.eclipse.org/index.php?title=RT_Shared_Editing&diff=10151RT Shared Editing2006-09-10T00:52:38Z<p>Codesurgeon.gmail.com: my name does not link to my CV directly anymore, directs to my new blog instead</p>
<hr />
<div><!-- Introduction --><br />
'''Project Lead''': [http://codesurgeon.blogspot.com/ Mustafa K. Isik]<br />
<br />
'''Mentor(s)''': Scott Lewis, Ken Gilmer<br />
<br />
==Motivation==<br />
The ''RT Shared Editor'', which I'll dub ''Cola'' ('''col'''l'''a'''borate) for now, is supposed to be a tool enabling developers to reap the benefits of pair programming within the Eclipse IDE.<br />
<br />
The term ''pair programming'' describes an activity in which two developers simultaneously work on a single development machine. <br />
<br />
Even though not new to the development community, ''pair programming'' has witnessed a significant rise in adoption over the last years. One of the main reasons being the inclusion to the set of [http://www.extremeprogramming.org/ eXtreme programming (aka ''XP'')] practices. Thus ''pair programming'' is especially, but certainly not only, popular among developers utilizing the values, principles and practices propagated by the ''XP'' methodology.<br />
<br />
The reasoning behind ''pair programming'', as articulated by software developer, author and ''XP'' figurehead [[RT Shared Editing#Resources|Kent Beck (2005 p.42)]] is manifold and pair programmer's activities are described as<br />
*keep each other focused and on task<br />
*brainstorm refinements to the system<br />
*clarify ideas<br />
*take initiative when their partner is stuck, lowering frustration<br />
*hold each other accountable to the team's practices<br />
<br />
From my own experience I can add, that programming in pairs has proved to be beneficial in<br />
*widening developers' horizons and perspectives on perceiving and tackling problems<br />
*increasing trust in one's own skills and generating awareness for areas requiring improvement<br />
*learning from more advanced developers<br />
**improving through working with less experienced devs, motivating to reflect on the essence of one's own practices<br />
*refining one's own communication skills<br />
<br />
===Current Situation===<br />
Tool-support for ''pair programming'' in [http://www.eclipse.org Eclipse] is pretty much non-existent. Pair programming sessions, as spontaneous as they might be arranged in some teams, usually are set up for longer periods of time, ranging anywhere from an hour to some four or five. Pairs consist of locally available developers.<br />
<br />
===Limitations & Problems===<br />
Geographical limitations do not permit for simple pair programming.<br />
Since individuals are required to sit in front of the same machine, they apparently have to be located at offices close to each other.<br />
Thus software development, not being a regionally bound activity, as proven by the sustained success and advances of open-source software and the nature of many open-source teams, has to be carried out without utilizing effective pair programming in many cases.<br />
<br />
Even when developers are located at the same work site, the effort to get two people set up together in front of a computer (drinks, resources, etc.) proves not to be worth for short programming or reviewing tasks, which sometimes are all that is required. This does not mean that coders do not occasionally sit down for such quick tasks, but from personal experience not as often as it might be beneficial for oneself and/or the code.<br />
<br />
Traditional instant messaging software does not lend itself for code communication among developers. Such software generally proves to be fairly feature-limited and catering to different target audiences. Theoretically it would lend itself for sending back and forth short code snippets at best, practically large-scale adoption of such behaviour has yet to be seen.<br />
<br />
Open-plan offices or group cube farm layouts do not support developers in utilizing pair programming benefits either, quickly degrading the workspace noise-level to that of an airport lobby (by the way, the true problem here would be of course the office layout, but the scope of changing that is unfortunately usually beyond the individual developer).<br />
<br />
Furthermore developers, who usually keep book resources in their personal work environment, end up being stripped of those for half of the time they are pair programming.<br />
<br />
===Resolution===<br />
''Cola'' is supposed to support collaborative work on code from disparate locations, minimizing organizational impact and improving on flexibility issues concerning pair programming.<br />
<br />
Developers are intended to be able to work simultaneously on a single source file, viewing changes made by other contributors in real-time and editing the most up-to-date version of the file at all times.<br />
<br />
The initial incarnation of ''Cola'' is to materialize in the form of an Eclipse IDE plug-in.<br />
<br />
==Consistency Maintenance==<br />
Maintaining consistency among shared data in a distributed real-time editing environment is of prime importance.<br />
<br />
Over the last decade a lot of thought has been dedicated to the research of domain-specific issues in real-time collaborative groupware systems. Chengzheng Sun and Clarence Ellis have authored a [[RT Shared Editing#Resources|paper (Sun & Ellis 1998)]] providing a thorough overview of such. The subsequent discussion of challenges specific to real-time collaborative editing is based on the referenced paper and intended to be self-sustaining in that you will not have to dig into academic research material to understand the challenges at hand.<br />
<!-- [[Image:cola_shared_editing_trivial.png|thumb|150px|right|idealistic editing scenario]] --><br />
[[Media:cola_shared_editing_trivial.png|Figure 1]] shows a somewhat ''idealistic'' scenario where communication lag between several editing sites remains without undesired consequences because operations are generated and executed at all sites in an orderly fashion.<br />
In a ''realistic'' distributed editing scenario, as depicted in [[Media:cola_shared_editing_nontrivial.png|Figure 2]], the need for consistency maintenance becomes apparent.<br />
===Challenges===<br />
====Divergence====<br />
<!-- [[Image:cola_shared_editing_nontrivial.png|thumb|400px|left|exemplary editing scenario]] this does not work! could it be that something is wrong with the eclipsepedia configuration? --><br />
Due to dependencies between operations originating from different editors on a shared document and suffering from propagation lag in a distributed environment, shared data state at different sites can divert from each other. This holds especially true for operations that are not [http://en.wikipedia.org/wiki/Commutative commutative] in execution order.<br />
{|border="1" cellpadding="5" cellspacing="0" align="center"<br />
|+''divergence'' in [[Media:cola_shared_editing_divergence.png|Figure 3]]<br />
|-<br />
! style="background:#efefef;" | site 1<br />
! style="background:#ffdead;" | state<br />
! style="background:#efefef;" | site 2<br />
! style="background:#ffdead;" | state<br />
! style="background:#efefef;" | site 3<br />
! style="background:#ffdead;" | state<br />
|-<br />
|A:''insert('a')''||a||A:''insert('a')''||a||A:''insert('a')''||a<br />
|-<br />
|C:''insert('c')''||'''ac'''||B:''insert('b')''||ab||B:''insert('b')''||ab<br />
|-<br />
|B:''insert('b')''||'''acb'''||C:''insert('c')''||'''abc'''||C:''insert('c')''||'''abc'''<br />
|}<br />
<br />
====Causality-violation====<br />
Each editing user's changes need to be communicated to the other editing sites. Independent from message generation times, notification of changes may arrive out-of-order. The resulting artifact for dependent operations is referred to as ''causality-violation''. The order in which operations A and B in [[Media:cola_shared_editing_nontrivial.png|Figure 2]] arrive at site 3 visualizes a typical case of ''causality-violation''. Operation B is generated at site 2 after the arrival and execution of operation A. The reversed arrival order of both operations at site 3 may result in an undefined operation B at site 3 (e.g. B is supposed to delete an insertion commited by A).<br />
Depending on the underlying communications protocol even the in-order arrival of editing operations originating from the same site [[Media:cola_shared_editing_causality.png|might not be guaranteed]].<br />
<br />
====Intention-violation====<br />
''Intention-violation'' is different from ''causality-violation'' in that it refers to the problems that arise when executing an operation on a document state altered by operations not having been executed at the operation's generation site.<br />
<br />
Operation C in [[Media:cola_shared_editing_nontrivial.png|Figure 2]] is defined/generated at site 3 on a document state neither affected by operation A nor B. Upon arrival and execution at sites 2 and 3 the respective document states have already been changed by operations A and B and can cause operation C to commit an unintended and undesired change.<br />
<br />
In contrast to the ''divergence''-problem, ''intention-violation'' cannot be resolved by a simple ''serialization protocol''.<br />
<br />
===Resolution Approach===<br />
====Look at the Sky & Spot JUPITER====<br />
A closer inspection of a paper titled "High-Latency, Low-Bandwidth Windowing in the Jupiter Collaboration System" [[RT Shared Editing#Resources| (Nichols ''et al'' 1995)]] reveals a very interesting approach to solving distributed-state synchronization problems in systems with more than two participating sites. <br />
<br />
Even though functionality-wise the more advanced approaches described in [[RT Shared Editing#Resources|(Sun & Ellis 1998)]] also represent solutions to the challenges in realizing ''Cola'', [[RT Shared Editing#Resources| (Nichols ''et al'' 1995)]] makes assumptions perfectly feasible for ''Cola'''s case that (in relative terms) greatly simplify the required concurrency-control algorithm.<br />
<br />
====Client-Server Communications====<br />
Much of the complexity of for instance the ''GROVE'' and ''REDUCE'' collaboration models stem from the fact, that they are designed for handling arbitrary communication-paths between each editing site. The ''JUPITER'' collaboration system on the other hand is [[Media:cola_client_server.png|designed around a central server]]. Utilizing the resulting communications topology, conflicting messages are resolved on the level of 2-way messaging between ''specific client - central server'' as opposed to [[Media:cola_n_way.png|n-way communications]]. <br />
<br />
Concerning ''causality-violation'', communications being effectively limited to 2-way / routed through the server document state, out-of-order arrival of messages adhering to a causal order, such as deletions referring to prior insertions, is prohibited. The central ordering instance, the server editing site, ensures, that all sites are updated in the right causal order.<br />
<br />
====Network Protocol====<br />
Considering [[Media:cola_shared_editing_causality.png|operations originating from the same site]], ''causality-violation'' of this specific type or more general reversed messaging, can be prohibited by using a ''network protocol'' not permitting for out-of-order communication of operations to the receiving site (either client or server). <br />
''Cola'''s network protocol will be chosen with respect to satisfaction of this property.<br />
<br />
====Optimistic Change Application====<br />
Responsiveness and immediate user feedback are important and expected features in an editor, therefore user operations are applied immediately to the local document state without awaiting server approval or undergoing any modifications.<br />
<br />
====Conflict Resolution via Operational Transformations====<br />
Even with the client-server topology in place and a 2-way messaging protocol ordering communications, preventing the out-of-order arrival of messages causing causality-violation, intention-violation can still occur. <br />
<br />
This becomes apparent when considering, that causality-violation is due to remote messages either from different sites or originating from a single site ''crossing on the wire'' on their way to the unaltered, i.e. consistent in document state concerning all prior operations, recipient. Ensuring the ordered arrival and execution of operations at the receiver site suffices to maintain consistency in document state.<br />
<br />
''Intention-violation'' on the other hand describes problems that occur due to operations being intended for execution on a certain document state, which is not available upon their arrival at the receiver. Locally generated and executed operations have altered the receiving site's document state during the transmission of remote operations. In this scenario, best described as mutually directed messages crossing on the wire, the same problem applies the other way around when exchanging sender and receiver labels on the sites.<br />
<br />
Application of operations on a document state different from the one they'd been intended for, bears the danger of intention violation, ranging from insertions at wrong places to deletion of wrong sections.<br />
Dropping and rolling back operations, in such a highly interactive application domain, is not an option, especially since local operations are executed immediately. <br />
<br />
Therefore ''intention-preserving transformations'' of such operations, i.e. ''operational transformations'', are key to ''Cola's'' resolution approach.<br />
<br />
<tt><br />
'''basic 2-way communication is of the form'''<br />
*client generates operation<br />
*client executes operation locally<br />
*client notifies server of operation<br />
*server receives operation<br />
*''in case of conflict:'' server '''transforms''' operation<br />
*server executes operation locally<br />
*server notifies all other clients of operation<br />
''for every receiving client''<br />
*client receives operation<br />
*''in case of conflict:'' client '''transforms''' operation<br />
*client executes operation locally<br />
</tt><br />
<br />
<br />
Presenting ''operational transformations'' as a means for conflict resolution, several immediate concerns arise<br />
#what ''are'' cola's operations on which to perform transformations<br />
#how do conflicting scenarios look like<br />
#what do operational transformations ''look like'' and<br />
#how are ''conflicts in document state'' to be ''detected'' in order to resolve them via transformations on operations?<br />
<br />
''Cola'' models all editing operations on documents as atomic ''deletions'' and ''insertions'' of single characters. Editing operations on more than a single char are broken down to atomic operations, as listed below.<br />
<pre><br />
&rarr; del(position)<br />
&rarr; del(from_position, to_position):=<br />
for(int i = from_position; i <= to_position; i++){<br />
del(i); <br />
}<br />
&rarr; ins(position, char)<br />
&rarr; ins(from_position, string):=<br />
for(int i = 0; i < string.length; i++){<br />
ins(from_position + i, string[i]);<br />
}<br />
</pre><br />
<br />
<br />
An example serves best to illustrate the features demanded of ''operational transformations''.<br />
<br />
{|border="1" cellpadding="3" cellspacing="0" align="center"<br />
|+''conflicting insertions''<br />
|-<br />
! style="background:#efefef;" | remote op.<br />
! style="background:#efefef;" | local op.<br />
! style="background:#ff8c00;" | state @ client 1<br />
! style="background:#6495ed;" | state @ client 2<br />
! style="background:#efefef;" | local op.<br />
! style="background:#efefef;" | remote op.<br />
|-<br />
| ||<font color=darkorange>ins(2,O)</font>||CRON||CRON||<font color=blue>ins(5,A)</font>|| <br />
|-<br />
|<font color=blue>ins(5,A)</font>|| ||C'''O'''RON||CRON'''A'''|| ||<font color=darkorange>ins(2,O)</font><br />
|-<br />
| || ||CORO<font color=red>'''A'''</font>N||CORON<font color=green>'''A'''</font>|| ||<br />
|}<br />
<br />
The user at site 2 intends to insert an ''A'' after the last ''N''. When the corresponding operation he issued and which was successfully applied to his local document, arrives at site 1 the document state has been altered by the insertion of another character at a lower index, thus shifting all subsequent characters' indeces by one. The untransformed execution of the insertion from site 2 on site 1's document results in intention-violation. The obvious solution in this case would be to increment the insertion op's index by one and executing <tt>ins(6,O)</tt><br />
<br />
Building on the information provided by the knowledge of the document states being one operation apart and knowing which two operations are intended for execution, abstraction and generalization lead to the specific operational transformation for two conflicting insertions. <br />
<br />
With regard to the ''conflicting insertions'' example, and the type of relation defined by transformations on operations, it becomes apparent that the transformation can be precisely described in terms of a function taking two conflicting operations at a time as input parameters and delivering two output operations modified for intention-preserving applicability at their respective destination sites.<br />
<br />
For brevity reasons, I will refer to cola's operational transformation function as '''<tt>coopt</tt>''' function (for '''co'''la '''op'''erational '''t'''ransformation).<br />
<pre><br />
coopt(ins(x, char_1), ins(y, char_2)):=<br />
{(ins(x, char_1), ins(y + 1, char_2)) , for x < y<br />
(ins(x + 1, char_1), ins(y, char_2)) , for x > y<br />
(noop, noop) , for x = y && char_1 == char_2<br />
serverside insertion comes first , for x = y && char_1 != char_2<br />
}<br />
</pre><br />
<br />
Using '''<tt>coopt</tt>''' for resolving the conflict between the insertion operations in our example, yields the same and intention-preserved document state at both sites.<br />
<br />
{|border="1" cellpadding="3" cellspacing="0" align="center"<br />
|+''conflicting insertions resolved via coopt''<br />
|-<br />
! style="background:#efefef;" | remote op.<br />
! style="background:#efefef;" | local op.<br />
! style="background:#ff8c00;" | state @ client 1<br />
! style="background:#6495ed;" | state @ client 2<br />
! style="background:#efefef;" | local op.<br />
! style="background:#efefef;" | remote op.<br />
|-<br />
| ||<font color=darkorange>ins(2,O)</font>||CRON||CRON||<font color=blue>ins(5,A)</font>|| <br />
|-<br />
|'''coopt('''<font color=blue>ins(5,A)</font>''',''' ins(2,O)''')'''<br>&rarr; <font color=blue>ins('''6''',A)</font>|| ||C'''O'''RON||CRON'''A'''|| ||'''coopt('''<font color=darkorange>ins(2,O)</font>''',''' ins(5,A)''')'''<br>&rarr; <font color=darkorange>ins(2,O)</font><br />
|-<br />
| || ||CORON<font color=green>'''A'''</font>||CORON<font color=green>'''A'''</font>|| ||<br />
|}<br />
<br />
Conflicts can also arise for deletions at both sites and deletion and insertion operations executed on the same document state at two different sites.<br />
<br />
{|border="1" cellpadding="3" cellspacing="0" align="center"<br />
|+''conflicting deletions''<br />
|-<br />
! style="background:#efefef;" | remote op.<br />
! style="background:#efefef;" | local op.<br />
! style="background:#ff8c00;" | state @ client 1<br />
! style="background:#6495ed;" | state @ client 2<br />
! style="background:#efefef;" | local op.<br />
! style="background:#efefef;" | remote op.<br />
|-<br />
| ||<font color=darkorange>del(6)</font>||MARIPOSA||MARIPOSA||<font color=blue>del(5)</font>|| <br />
|-<br />
|<font color=blue>del(5)</font>|| ||MARIPSA||MARIOSA|| ||<font color=darkorange>del(6)</font><br />
|-<br />
| || ||MARISA||MARIO<font color=red>'''A'''</font>|| ||<br />
|}<br />
<br />
The specific conflict in the ''conflicting deletions'' table can be resolved by decrementing the index of the <tt>del(6)</tt> operation originating from site 1 by one upon arrival at and prior to execution at site 2.<br />
<br />
As for insertions, '''<tt>coopt</tt>''' handles conflicting deletions in a general way.<br />
<pre><br />
coopt(del(x), del(y):=<br />
{(del(x), del(y - 1) , for x < y<br />
(del(x - 1), del(y) , for x > y<br />
(noop, noop) , for x = y <br />
}<br />
</pre><br />
Transforming remote delete operations defined on document states one operation apart from the local state, results in conflict free convergence.<br />
<br />
{|border="1" cellpadding="3" cellspacing="0" align="center"<br />
|+''conflicting deletions resolved via coopt''<br />
|-<br />
! style="background:#efefef;" | remote op.<br />
! style="background:#efefef;" | local op.<br />
! style="background:#ff8c00;" | state @ client 1<br />
! style="background:#6495ed;" | state @ client 2<br />
! style="background:#efefef;" | local op.<br />
! style="background:#efefef;" | remote op.<br />
|-<br />
| ||<font color=darkorange>del(6)</font>||MARIPOSA||MARIPOSA||<font color=blue>del(5)</font>|| <br />
|-<br />
|'''coopt('''<font color=blue>del(5)</font>''',''' del(6)''')'''<br>&rarr; <font color=blue>del(5)</font>|| ||MARIPSA||MARIOSA|| ||'''coopt('''<font color=darkorange>del(6)</font>''',''' del(5)''')'''<br>&rarr; <font color=darkorange>del('''5''')</font><br />
|-<br />
| || ||MARISA||MARISA|| ||<br />
|}<br />
<br />
''Cola'' provides two more operations, which also need to be handled by '''<tt>coopt</tt>'''. These last operations are intended to improve on the collaborative experience and are of non-editing nature. Both operations are user-specific in that every user's cursor, possibly each in a different color, is replicated among editing sites. This is to make remote user operations more comprehensible for the respective local user. The same applies to the user-specific highlighting of editor contents.<br />
<pre><br />
&rarr; cursor(position, user)<br />
&rarr; highlight(position, user)<br />
&rarr; highlight(from_position, to_position, user):=<br />
for(int i = from_position; i <= to_position; i++){<br />
highlight(i, user); <br />
}<br />
</pre><br />
<br />
====Concurrency Algorithm====<br />
Summarizing the previous section and giving a motivation for the one at hand, ''operational transformations'' are applicable on operations, defined on the same document state at different sites. When reaching their respective destination sites in such scenarios, the remote sites' document state diverges by ''one operation''. The transformation modifies the incoming operation with respect to the operation that has been executed at the receiving site, so that ''intention-preservation'' for the incoming operation is satisfied.<br />
<br />
In cases where the local, receiving document state ''diverges by more than one (locally executed) operation'' compared to the state at a remote site sending an operation, the mechanism of ''operational transformations'' cannot be utilized directly. The previously iterated preconditions for the application of such are not met.<br />
<br />
A ''concurrency algorithm'' takes care of detecting conflicting situations and meeting requirements for resolution via ''operational transformations''.<br />
<br />
[[Media:cola_shared_editing_statespace_simple.png|Figure 4]] features an exemplary graph of the state-space a client and the server editing site roam during a session. The diagram visualizes a scenario where during editing, document states at client and server side diverge by a single operation respectively and get resolved via operational transformations.<br />
<br />
As indicated, the need for a concurrency algorithm arises in part from the non-applicability of operational transformations on document states diverging by more than a single operation, as presented in [[Media:cola_shared_editing_statespace_divergence_by_more_than_one_op.png|Figure 5]]. The graph shows client and server sites diverging as of state <tt>(0,0)</tt>. The client site receives the server message, which it directly transforms via the <tt>coopt</tt>-function and subsequently applies to its document state. Let <tt>c</tt> be the initial client application, and <tt>s1</tt> the first server-site operation. <tt>coopt(c,s1)</tt> results in a 2-tuple <tt>(c',s1')</tt> of which the parameters are characterized by the equation <tt>c &#x2299; s1' = s1 &#x2299; c'</tt> Interpreting the equation, the subsequent application of <tt>s1'</tt> to a document state <tt>c</tt> results in the same state as applying <tt>s1</tt> followed by <tt>c'</tt>. This is by definition the exact thing the operational transformation function <tt>coopt</tt> is to take care of.<br />
The interesting part is when the client receives another message <tt>s2</tt>, having been generated on a document state only incorporating operation <tt>s1</tt>, <tt>s2</tt> cannot be applied to the client state <tt>c &#x2299; s1'</tt> directly. But since the client already contains <tt>s1</tt>, which just had been applied to the client-local state via <tt>s1'</tt> in the previous step, the precondition for conflict-resolution via <tt>coopt</tt>, i.e. divergence by a single operation, is met. <br />
<br />
''The important and central question is what other parameter is supposed to go into <tt>coopt</tt> with <tt>s2</tt>.''<br />
<br />
Considering that the server-state did not contain <tt>c</tt> when generating <tt>s2</tt>, <tt>c</tt> in some form resembles/relates to the deviating operation. With <tt>c'</tt> we are aware of a transformed version of operation <tt>c</tt>, which could be applied to an <tt>s1</tt> document state in an intention-preserving/non-destructive manner. Thus <tt>c'</tt> is to be the other parameter to be respected when transforming operation <tt>s2</tt> for applicability on the client side. [[Media:cola_shared_editing_statespace_divergence_by_more_than_one_op.png|Figure 5]] has concrete operations substituted for <tt>c, s1, and s2</tt>.<br />
<br />
{|border="1" cellpadding="3" cellspacing="0" align="center"<br />
|+''mapping for exemplary operations in Figure 5''<br />
|-<br />
! style="background:#efefef;" | <tt>c</tt><br />
! style="background:#efefef;" | <tt>c'</tt><br />
! style="background:#efefef;" | <tt>c' '</tt><br />
! style="background:#6495ed;" | <tt>s1</tt><br />
! style="background:#6495ed;" | <tt>s1'</tt><br />
! style="background:#ff8c00;" | <tt>s2</tt><br />
! style="background:#ff8c00;" | <tt>s2'</tt><br />
|-<br />
|del(5)||del(5)||del(5)||del(9)||del(8)||del(8)||del(7) <br />
|}<br />
<br />
Assuming that in state <tt>(0,2)</tt> the server receives the client-message originating from state <tt>(0,0)</tt> and communicating the client-operation <tt>c</tt> (i.e. <tt>del(5)</tt> in [[Media:cola_shared_editing_statespace_divergence_by_more_than_one_op.png|Figure 5]]), it becomes once again apparent, that an operational transformation via <tt>coopt(c,s2)</tt> won't suffice to reach consistent document states on client and server sides.<br />
<br />
The server, being in a document state off by more than one diverging operation considering the state on which <tt>c</tt> had been defined, some course of action is needed to transform <tt>c</tt> with respect to all operations, that have already been applied on the server state, i.e. regarding not only <tt>s2</tt>, but also <tt>s1</tt>.<br />
<br />
''obtaining an intention-preserving instance of operation <tt>c</tt> for application on state <tt>(0,2)</tt>''<br />
<pre><br />
coopt(c,s1)&rarr;(c',s1'); //use c' for transformation against s2<br />
&rArr; coopt(c',s2)&rarr;(c'',s2'); //c'' is OK for application on state (0,2)<br />
</pre><br />
''different notation for the same procedure''<br />
<pre><br />
applyLeftOfResult(coopt(leftOfResult(coopt(c,s1)&rarr;(c',s1')),s2) &rarr; (c'',s2'));<br />
</pre><br />
[[Media:cola_shared_editing_statespace_divergence_by_more_than_one_op_closure.png|Figure 6]] extends the editing scenario accordingly.<br />
=====the algorithm=====<br />
Having closely inspected an example where operational transformations cannot be utilized directly to resolve conflicting situations, we understand the need for an ''encapsulating'' algorithm, taking care of meeting the proper preconditions for the application of '''<tt>coopt</tt>'''.<br />
<br />
Interpreting the state-space graph in [[Media:cola_shared_editing_statespace_algorithm_client_perspective.png|Figure 7]] as how a client perceives an editing session and the processing of local and incoming operations, leads to the required functionality of the controlling ''concurrency algorithm''. From the client's perspective the server was last known to be in state <tt>(x,y)</tt>. The client state has moved on by <tt>k</tt> locally generated and executed operations since the last server-to-client communication. All <tt>k</tt> messages generated by the client have been communicated to the server, so that the next server-generated message is to originate from one of the states between <tt>(x,y)</tt> and <tt>(x+'''k''',y)</tt>. As demonstrated in the introductory example to this subsection, an incoming operation, originating from a state <tt>(x+'''i''',y)</tt>, where i &isin; {0,..,(k-1)}, could not be directly <tt>coopt</tt>'ed with the most recent client operation '''<tt>k</tt>'''. Instead the received server operation has to be consecutively <tt>coopt</tt>'ed with each operation starting with the one generated by the client on the same state as the server operation originated from, leading up to and including the state of operation <tt>k-1</tt>. That is each succeeding <tt>coopt</tt> is called with the result of the transformed server message from the preceding <tt>coopt</tt> and the respective state's local operation. The last <tt>coopt</tt>, which is '''<tt>coopt(i*, k)</tt>''', where ''i* := indicates properly transformed server message/operation i'', yields the intention-preserving transformed operation <tt>i^(*+1)</tt> applicable on the client state and taking it to state '''<tt>(x+k, y+1)</tt>'''. <br />
<br />
Since the ''cola'' architecture is designed to have the server only differ from the clients in that it serves as central notification instance, the algorithm also applies to the server site.<br />
<br />
<br />
<br />
==Integration into Eclipse Communication Framework==<br />
The '''org.eclipse.ecf.example.collab.editor''' plugin provides a [[Example_Shared_Text_Editor|shared editor]] implementation based on the [[Eclipse_Communication_Framework_Project|Eclipse Communication Framework]]. <br />
<br />
It differs from the ''cola'' approach in that it does not utilize advanced mechanisms, such as ''operational transformations'' and a ''concurrency algorithm'', to ensure consistency in document states at discrete sites while maintaining the effects of every editing operation.<br />
Instead of communicating atomic editing operations to each remote site, where state-specific transformations ensure consistent applicability, the [[Example_Shared_Text_Editor|exemplary shared editor]] sends the entire document content to session participants upon local application of an operation. The incoming document overwrites each receiver's copy. In case of communications ''crossing on the wire'', editing information is lost and document states divert.<br />
<br />
In order to maximize code reuse, ''cola's'' sample implementation, '''org.eclipse.ecf.example.sharededitor.cola''', builds on the prior [[Example_Shared_Text_Editor|shared editor]], modifying and extending its functionality as needed. Thus, once deployed and even though the core communications are handled very differently, setting up and running either editor is very much alike.<br />
<br />
===Take a Sip===<br />
====The Cola Source====<br />
''Cola's'' current incarnation lives in a CVS repository at the [http://osuosl.org/ Oregon State University Open Source Lab]. You can get your hands on the sourcecode via anonymous access.<br />
<pre><br />
:pserver:anonymous@ecf1.osuosl.org:/ecf/applications/org.eclipse.ecf.example.sharededitor.cola<br />
</pre><br />
<br />
====Set it Up & Get it Running====<br />
As for obtaining the rest of the code required to build and run ''cola'', consult the [http://www.eclipse.org/ecf/resources.html ECF development resources page] and get the latest sources. A ''team project set'' is provided to greatly simplify your workspace setup.<br />
<br />
Consult the straightforward [[Example_Shared_Text_Editor|how-to]] on the prior shared editor, selecting the ''cola''-specific menu entries at steps '''5.''' and '''7.''', to set up a ''cola'' editing session.<br />
<br />
''Cola'' is stable and functional apart from some minor restrictions, which are being worked on. Currently the following restrictions apply:<br />
*document sharing is limited to two sites<br />
*both participants have to join, prior to editing<br />
*multi-character operations, such as copy & paste of multiple characters or bulk deletion of such, are yet to be implemented.<br />
<br />
==Resources==<br />
===Meeting Notes=== <br />
*[[Eclipse_Communication_Framework_Project|ECF Conference Calls]]<br />
*[[Monday May 29, 2006]]<br />
<br />
===Papers & Books===<br />
*Beck, K 2005, ''Extreme Programming Explained - Embrace Change'', 2nd Ed., Addison-Wesley, Boston MA (USA), p. 42<br />
*Sun, C & Ellis, C 1998, [http://citeseer.ist.psu.edu/sun98operational.html ''Operational Transformation in Real-Time Group Editors: Issues, Algorithms, and Achievements''], Proceedings of the ACM Conference on Computer-Supported Cooperative Work, Seattle WA (USA), pp. 59-68<br />
*Nichols, D, Curtis, P, Dixon, M & Lamping, J 1995, [http://portal.acm.org/citation.cfm?coll=GUIDE&dl=GUIDE&id=215706 ''High-Latency, low-bandwidth windowing in the Jupiter collaboration system''], Proceedings of the 8th annual ACM symposium on User interface and software technology, Pittsburgh PA (USA), pp. 111-120</div>Codesurgeon.gmail.comhttps://wiki.eclipse.org/index.php?title=RT_Shared_Editing&diff=9355RT Shared Editing2006-08-29T19:45:59Z<p>Codesurgeon.gmail.com: inserted cola plug-in name</p>
<hr />
<div><!-- Introduction --><br />
'''Project Lead''': [http://www.codesurgeon.us/~mustafa/wiki/index.php/Mustafa%27s_Page Mustafa K. Isik]<br />
<br />
'''Mentor(s)''': Scott Lewis, Ken Gilmer<br />
<br />
==Motivation==<br />
The ''RT Shared Editor'', which I'll dub ''Cola'' ('''col'''l'''a'''borate) for now, is supposed to be a tool enabling developers to reap the benefits of pair programming within the Eclipse IDE.<br />
<br />
The term ''pair programming'' describes an activity in which two developers simultaneously work on a single development machine. <br />
<br />
Even though not new to the development community, ''pair programming'' has witnessed a significant rise in adoption over the last years. One of the main reasons being the inclusion to the set of [http://www.extremeprogramming.org/ eXtreme programming (aka ''XP'')] practices. Thus ''pair programming'' is especially, but certainly not only, popular among developers utilizing the values, principles and practices propagated by the ''XP'' methodology.<br />
<br />
The reasoning behind ''pair programming'', as articulated by software developer, author and ''XP'' figurehead [[RT Shared Editing#Resources|Kent Beck (2005 p.42)]] is manifold and pair programmer's activities are described as<br />
*keep each other focused and on task<br />
*brainstorm refinements to the system<br />
*clarify ideas<br />
*take initiative when their partner is stuck, lowering frustration<br />
*hold each other accountable to the team's practices<br />
<br />
From my own experience I can add, that programming in pairs has proved to be beneficial in<br />
*widening developers' horizons and perspectives on perceiving and tackling problems<br />
*increasing trust in one's own skills and generating awareness for areas requiring improvement<br />
*learning from more advanced developers<br />
**improving through working with less experienced devs, motivating to reflect on the essence of one's own practices<br />
*refining one's own communication skills<br />
<br />
===Current Situation===<br />
Tool-support for ''pair programming'' in [http://www.eclipse.org Eclipse] is pretty much non-existent. Pair programming sessions, as spontaneous as they might be arranged in some teams, usually are set up for longer periods of time, ranging anywhere from an hour to some four or five. Pairs consist of locally available developers.<br />
<br />
===Limitations & Problems===<br />
Geographical limitations do not permit for simple pair programming.<br />
Since individuals are required to sit in front of the same machine, they apparently have to be located at offices close to each other.<br />
Thus software development, not being a regionally bound activity, as proven by the sustained success and advances of open-source software and the nature of many open-source teams, has to be carried out without utilizing effective pair programming in many cases.<br />
<br />
Even when developers are located at the same work site, the effort to get two people set up together in front of a computer (drinks, resources, etc.) proves not to be worth for short programming or reviewing tasks, which sometimes are all that is required. This does not mean that coders do not occasionally sit down for such quick tasks, but from personal experience not as often as it might be beneficial for oneself and/or the code.<br />
<br />
Traditional instant messaging software does not lend itself for code communication among developers. Such software generally proves to be fairly feature-limited and catering to different target audiences. Theoretically it would lend itself for sending back and forth short code snippets at best, practically large-scale adoption of such behaviour has yet to be seen.<br />
<br />
Open-plan offices or group cube farm layouts do not support developers in utilizing pair programming benefits either, quickly degrading the workspace noise-level to that of an airport lobby (by the way, the true problem here would be of course the office layout, but the scope of changing that is unfortunately usually beyond the individual developer).<br />
<br />
Furthermore developers, who usually keep book resources in their personal work environment, end up being stripped of those for half of the time they are pair programming.<br />
<br />
===Resolution===<br />
''Cola'' is supposed to support collaborative work on code from disparate locations, minimizing organizational impact and improving on flexibility issues concerning pair programming.<br />
<br />
Developers are intended to be able to work simultaneously on a single source file, viewing changes made by other contributors in real-time and editing the most up-to-date version of the file at all times.<br />
<br />
The initial incarnation of ''Cola'' is to materialize in the form of an Eclipse IDE plug-in.<br />
<br />
==Consistency Maintenance==<br />
Maintaining consistency among shared data in a distributed real-time editing environment is of prime importance.<br />
<br />
Over the last decade a lot of thought has been dedicated to the research of domain-specific issues in real-time collaborative groupware systems. Chengzheng Sun and Clarence Ellis have authored a [[RT Shared Editing#Resources|paper (Sun & Ellis 1998)]] providing a thorough overview of such. The subsequent discussion of challenges specific to real-time collaborative editing is based on the referenced paper and intended to be self-sustaining in that you will not have to dig into academic research material to understand the challenges at hand.<br />
<!-- [[Image:cola_shared_editing_trivial.png|thumb|150px|right|idealistic editing scenario]] --><br />
[[Media:cola_shared_editing_trivial.png|Figure 1]] shows a somewhat ''idealistic'' scenario where communication lag between several editing sites remains without undesired consequences because operations are generated and executed at all sites in an orderly fashion.<br />
In a ''realistic'' distributed editing scenario, as depicted in [[Media:cola_shared_editing_nontrivial.png|Figure 2]], the need for consistency maintenance becomes apparent.<br />
===Challenges===<br />
====Divergence====<br />
<!-- [[Image:cola_shared_editing_nontrivial.png|thumb|400px|left|exemplary editing scenario]] this does not work! could it be that something is wrong with the eclipsepedia configuration? --><br />
Due to dependencies between operations originating from different editors on a shared document and suffering from propagation lag in a distributed environment, shared data state at different sites can divert from each other. This holds especially true for operations that are not [http://en.wikipedia.org/wiki/Commutative commutative] in execution order.<br />
{|border="1" cellpadding="5" cellspacing="0" align="center"<br />
|+''divergence'' in [[Media:cola_shared_editing_divergence.png|Figure 3]]<br />
|-<br />
! style="background:#efefef;" | site 1<br />
! style="background:#ffdead;" | state<br />
! style="background:#efefef;" | site 2<br />
! style="background:#ffdead;" | state<br />
! style="background:#efefef;" | site 3<br />
! style="background:#ffdead;" | state<br />
|-<br />
|A:''insert('a')''||a||A:''insert('a')''||a||A:''insert('a')''||a<br />
|-<br />
|C:''insert('c')''||'''ac'''||B:''insert('b')''||ab||B:''insert('b')''||ab<br />
|-<br />
|B:''insert('b')''||'''acb'''||C:''insert('c')''||'''abc'''||C:''insert('c')''||'''abc'''<br />
|}<br />
<br />
====Causality-violation====<br />
Each editing user's changes need to be communicated to the other editing sites. Independent from message generation times, notification of changes may arrive out-of-order. The resulting artifact for dependent operations is referred to as ''causality-violation''. The order in which operations A and B in [[Media:cola_shared_editing_nontrivial.png|Figure 2]] arrive at site 3 visualizes a typical case of ''causality-violation''. Operation B is generated at site 2 after the arrival and execution of operation A. The reversed arrival order of both operations at site 3 may result in an undefined operation B at site 3 (e.g. B is supposed to delete an insertion commited by A).<br />
Depending on the underlying communications protocol even the in-order arrival of editing operations originating from the same site [[Media:cola_shared_editing_causality.png|might not be guaranteed]].<br />
<br />
====Intention-violation====<br />
''Intention-violation'' is different from ''causality-violation'' in that it refers to the problems that arise when executing an operation on a document state altered by operations not having been executed at the operation's generation site.<br />
<br />
Operation C in [[Media:cola_shared_editing_nontrivial.png|Figure 2]] is defined/generated at site 3 on a document state neither affected by operation A nor B. Upon arrival and execution at sites 2 and 3 the respective document states have already been changed by operations A and B and can cause operation C to commit an unintended and undesired change.<br />
<br />
In contrast to the ''divergence''-problem, ''intention-violation'' cannot be resolved by a simple ''serialization protocol''.<br />
<br />
===Resolution Approach===<br />
====Look at the Sky & Spot JUPITER====<br />
A closer inspection of a paper titled "High-Latency, Low-Bandwidth Windowing in the Jupiter Collaboration System" [[RT Shared Editing#Resources| (Nichols ''et al'' 1995)]] reveals a very interesting approach to solving distributed-state synchronization problems in systems with more than two participating sites. <br />
<br />
Even though functionality-wise the more advanced approaches described in [[RT Shared Editing#Resources|(Sun & Ellis 1998)]] also represent solutions to the challenges in realizing ''Cola'', [[RT Shared Editing#Resources| (Nichols ''et al'' 1995)]] makes assumptions perfectly feasible for ''Cola'''s case that (in relative terms) greatly simplify the required concurrency-control algorithm.<br />
<br />
====Client-Server Communications====<br />
Much of the complexity of for instance the ''GROVE'' and ''REDUCE'' collaboration models stem from the fact, that they are designed for handling arbitrary communication-paths between each editing site. The ''JUPITER'' collaboration system on the other hand is [[Media:cola_client_server.png|designed around a central server]]. Utilizing the resulting communications topology, conflicting messages are resolved on the level of 2-way messaging between ''specific client - central server'' as opposed to [[Media:cola_n_way.png|n-way communications]]. <br />
<br />
Concerning ''causality-violation'', communications being effectively limited to 2-way / routed through the server document state, out-of-order arrival of messages adhering to a causal order, such as deletions referring to prior insertions, is prohibited. The central ordering instance, the server editing site, ensures, that all sites are updated in the right causal order.<br />
<br />
====Network Protocol====<br />
Considering [[Media:cola_shared_editing_causality.png|operations originating from the same site]], ''causality-violation'' of this specific type or more general reversed messaging, can be prohibited by using a ''network protocol'' not permitting for out-of-order communication of operations to the receiving site (either client or server). <br />
''Cola'''s network protocol will be chosen with respect to satisfaction of this property.<br />
<br />
====Optimistic Change Application====<br />
Responsiveness and immediate user feedback are important and expected features in an editor, therefore user operations are applied immediately to the local document state without awaiting server approval or undergoing any modifications.<br />
<br />
====Conflict Resolution via Operational Transformations====<br />
Even with the client-server topology in place and a 2-way messaging protocol ordering communications, preventing the out-of-order arrival of messages causing causality-violation, intention-violation can still occur. <br />
<br />
This becomes apparent when considering, that causality-violation is due to remote messages either from different sites or originating from a single site ''crossing on the wire'' on their way to the unaltered, i.e. consistent in document state concerning all prior operations, recipient. Ensuring the ordered arrival and execution of operations at the receiver site suffices to maintain consistency in document state.<br />
<br />
''Intention-violation'' on the other hand describes problems that occur due to operations being intended for execution on a certain document state, which is not available upon their arrival at the receiver. Locally generated and executed operations have altered the receiving site's document state during the transmission of remote operations. In this scenario, best described as mutually directed messages crossing on the wire, the same problem applies the other way around when exchanging sender and receiver labels on the sites.<br />
<br />
Application of operations on a document state different from the one they'd been intended for, bears the danger of intention violation, ranging from insertions at wrong places to deletion of wrong sections.<br />
Dropping and rolling back operations, in such a highly interactive application domain, is not an option, especially since local operations are executed immediately. <br />
<br />
Therefore ''intention-preserving transformations'' of such operations, i.e. ''operational transformations'', are key to ''Cola's'' resolution approach.<br />
<br />
<tt><br />
'''basic 2-way communication is of the form'''<br />
*client generates operation<br />
*client executes operation locally<br />
*client notifies server of operation<br />
*server receives operation<br />
*''in case of conflict:'' server '''transforms''' operation<br />
*server executes operation locally<br />
*server notifies all other clients of operation<br />
''for every receiving client''<br />
*client receives operation<br />
*''in case of conflict:'' client '''transforms''' operation<br />
*client executes operation locally<br />
</tt><br />
<br />
<br />
Presenting ''operational transformations'' as a means for conflict resolution, several immediate concerns arise<br />
#what ''are'' cola's operations on which to perform transformations<br />
#how do conflicting scenarios look like<br />
#what do operational transformations ''look like'' and<br />
#how are ''conflicts in document state'' to be ''detected'' in order to resolve them via transformations on operations?<br />
<br />
''Cola'' models all editing operations on documents as atomic ''deletions'' and ''insertions'' of single characters. Editing operations on more than a single char are broken down to atomic operations, as listed below.<br />
<pre><br />
&rarr; del(position)<br />
&rarr; del(from_position, to_position):=<br />
for(int i = from_position; i <= to_position; i++){<br />
del(i); <br />
}<br />
&rarr; ins(position, char)<br />
&rarr; ins(from_position, string):=<br />
for(int i = 0; i < string.length; i++){<br />
ins(from_position + i, string[i]);<br />
}<br />
</pre><br />
<br />
<br />
An example serves best to illustrate the features demanded of ''operational transformations''.<br />
<br />
{|border="1" cellpadding="3" cellspacing="0" align="center"<br />
|+''conflicting insertions''<br />
|-<br />
! style="background:#efefef;" | remote op.<br />
! style="background:#efefef;" | local op.<br />
! style="background:#ff8c00;" | state @ client 1<br />
! style="background:#6495ed;" | state @ client 2<br />
! style="background:#efefef;" | local op.<br />
! style="background:#efefef;" | remote op.<br />
|-<br />
| ||<font color=darkorange>ins(2,O)</font>||CRON||CRON||<font color=blue>ins(5,A)</font>|| <br />
|-<br />
|<font color=blue>ins(5,A)</font>|| ||C'''O'''RON||CRON'''A'''|| ||<font color=darkorange>ins(2,O)</font><br />
|-<br />
| || ||CORO<font color=red>'''A'''</font>N||CORON<font color=green>'''A'''</font>|| ||<br />
|}<br />
<br />
The user at site 2 intends to insert an ''A'' after the last ''N''. When the corresponding operation he issued and which was successfully applied to his local document, arrives at site 1 the document state has been altered by the insertion of another character at a lower index, thus shifting all subsequent characters' indeces by one. The untransformed execution of the insertion from site 2 on site 1's document results in intention-violation. The obvious solution in this case would be to increment the insertion op's index by one and executing <tt>ins(6,O)</tt><br />
<br />
Building on the information provided by the knowledge of the document states being one operation apart and knowing which two operations are intended for execution, abstraction and generalization lead to the specific operational transformation for two conflicting insertions. <br />
<br />
With regard to the ''conflicting insertions'' example, and the type of relation defined by transformations on operations, it becomes apparent that the transformation can be precisely described in terms of a function taking two conflicting operations at a time as input parameters and delivering two output operations modified for intention-preserving applicability at their respective destination sites.<br />
<br />
For brevity reasons, I will refer to cola's operational transformation function as '''<tt>coopt</tt>''' function (for '''co'''la '''op'''erational '''t'''ransformation).<br />
<pre><br />
coopt(ins(x, char_1), ins(y, char_2)):=<br />
{(ins(x, char_1), ins(y + 1, char_2)) , for x < y<br />
(ins(x + 1, char_1), ins(y, char_2)) , for x > y<br />
(noop, noop) , for x = y && char_1 == char_2<br />
serverside insertion comes first , for x = y && char_1 != char_2<br />
}<br />
</pre><br />
<br />
Using '''<tt>coopt</tt>''' for resolving the conflict between the insertion operations in our example, yields the same and intention-preserved document state at both sites.<br />
<br />
{|border="1" cellpadding="3" cellspacing="0" align="center"<br />
|+''conflicting insertions resolved via coopt''<br />
|-<br />
! style="background:#efefef;" | remote op.<br />
! style="background:#efefef;" | local op.<br />
! style="background:#ff8c00;" | state @ client 1<br />
! style="background:#6495ed;" | state @ client 2<br />
! style="background:#efefef;" | local op.<br />
! style="background:#efefef;" | remote op.<br />
|-<br />
| ||<font color=darkorange>ins(2,O)</font>||CRON||CRON||<font color=blue>ins(5,A)</font>|| <br />
|-<br />
|'''coopt('''<font color=blue>ins(5,A)</font>''',''' ins(2,O)''')'''<br>&rarr; <font color=blue>ins('''6''',A)</font>|| ||C'''O'''RON||CRON'''A'''|| ||'''coopt('''<font color=darkorange>ins(2,O)</font>''',''' ins(5,A)''')'''<br>&rarr; <font color=darkorange>ins(2,O)</font><br />
|-<br />
| || ||CORON<font color=green>'''A'''</font>||CORON<font color=green>'''A'''</font>|| ||<br />
|}<br />
<br />
Conflicts can also arise for deletions at both sites and deletion and insertion operations executed on the same document state at two different sites.<br />
<br />
{|border="1" cellpadding="3" cellspacing="0" align="center"<br />
|+''conflicting deletions''<br />
|-<br />
! style="background:#efefef;" | remote op.<br />
! style="background:#efefef;" | local op.<br />
! style="background:#ff8c00;" | state @ client 1<br />
! style="background:#6495ed;" | state @ client 2<br />
! style="background:#efefef;" | local op.<br />
! style="background:#efefef;" | remote op.<br />
|-<br />
| ||<font color=darkorange>del(6)</font>||MARIPOSA||MARIPOSA||<font color=blue>del(5)</font>|| <br />
|-<br />
|<font color=blue>del(5)</font>|| ||MARIPSA||MARIOSA|| ||<font color=darkorange>del(6)</font><br />
|-<br />
| || ||MARISA||MARIO<font color=red>'''A'''</font>|| ||<br />
|}<br />
<br />
The specific conflict in the ''conflicting deletions'' table can be resolved by decrementing the index of the <tt>del(6)</tt> operation originating from site 1 by one upon arrival at and prior to execution at site 2.<br />
<br />
As for insertions, '''<tt>coopt</tt>''' handles conflicting deletions in a general way.<br />
<pre><br />
coopt(del(x), del(y):=<br />
{(del(x), del(y - 1) , for x < y<br />
(del(x - 1), del(y) , for x > y<br />
(noop, noop) , for x = y <br />
}<br />
</pre><br />
Transforming remote delete operations defined on document states one operation apart from the local state, results in conflict free convergence.<br />
<br />
{|border="1" cellpadding="3" cellspacing="0" align="center"<br />
|+''conflicting deletions resolved via coopt''<br />
|-<br />
! style="background:#efefef;" | remote op.<br />
! style="background:#efefef;" | local op.<br />
! style="background:#ff8c00;" | state @ client 1<br />
! style="background:#6495ed;" | state @ client 2<br />
! style="background:#efefef;" | local op.<br />
! style="background:#efefef;" | remote op.<br />
|-<br />
| ||<font color=darkorange>del(6)</font>||MARIPOSA||MARIPOSA||<font color=blue>del(5)</font>|| <br />
|-<br />
|'''coopt('''<font color=blue>del(5)</font>''',''' del(6)''')'''<br>&rarr; <font color=blue>del(5)</font>|| ||MARIPSA||MARIOSA|| ||'''coopt('''<font color=darkorange>del(6)</font>''',''' del(5)''')'''<br>&rarr; <font color=darkorange>del('''5''')</font><br />
|-<br />
| || ||MARISA||MARISA|| ||<br />
|}<br />
<br />
''Cola'' provides two more operations, which also need to be handled by '''<tt>coopt</tt>'''. These last operations are intended to improve on the collaborative experience and are of non-editing nature. Both operations are user-specific in that every user's cursor, possibly each in a different color, is replicated among editing sites. This is to make remote user operations more comprehensible for the respective local user. The same applies to the user-specific highlighting of editor contents.<br />
<pre><br />
&rarr; cursor(position, user)<br />
&rarr; highlight(position, user)<br />
&rarr; highlight(from_position, to_position, user):=<br />
for(int i = from_position; i <= to_position; i++){<br />
highlight(i, user); <br />
}<br />
</pre><br />
<br />
====Concurrency Algorithm====<br />
Summarizing the previous section and giving a motivation for the one at hand, ''operational transformations'' are applicable on operations, defined on the same document state at different sites. When reaching their respective destination sites in such scenarios, the remote sites' document state diverges by ''one operation''. The transformation modifies the incoming operation with respect to the operation that has been executed at the receiving site, so that ''intention-preservation'' for the incoming operation is satisfied.<br />
<br />
In cases where the local, receiving document state ''diverges by more than one (locally executed) operation'' compared to the state at a remote site sending an operation, the mechanism of ''operational transformations'' cannot be utilized directly. The previously iterated preconditions for the application of such are not met.<br />
<br />
A ''concurrency algorithm'' takes care of detecting conflicting situations and meeting requirements for resolution via ''operational transformations''.<br />
<br />
[[Media:cola_shared_editing_statespace_simple.png|Figure 4]] features an exemplary graph of the state-space a client and the server editing site roam during a session. The diagram visualizes a scenario where during editing, document states at client and server side diverge by a single operation respectively and get resolved via operational transformations.<br />
<br />
As indicated, the need for a concurrency algorithm arises in part from the non-applicability of operational transformations on document states diverging by more than a single operation, as presented in [[Media:cola_shared_editing_statespace_divergence_by_more_than_one_op.png|Figure 5]]. The graph shows client and server sites diverging as of state <tt>(0,0)</tt>. The client site receives the server message, which it directly transforms via the <tt>coopt</tt>-function and subsequently applies to its document state. Let <tt>c</tt> be the initial client application, and <tt>s1</tt> the first server-site operation. <tt>coopt(c,s1)</tt> results in a 2-tuple <tt>(c',s1')</tt> of which the parameters are characterized by the equation <tt>c &#x2299; s1' = s1 &#x2299; c'</tt> Interpreting the equation, the subsequent application of <tt>s1'</tt> to a document state <tt>c</tt> results in the same state as applying <tt>s1</tt> followed by <tt>c'</tt>. This is by definition the exact thing the operational transformation function <tt>coopt</tt> is to take care of.<br />
The interesting part is when the client receives another message <tt>s2</tt>, having been generated on a document state only incorporating operation <tt>s1</tt>, <tt>s2</tt> cannot be applied to the client state <tt>c &#x2299; s1'</tt> directly. But since the client already contains <tt>s1</tt>, which just had been applied to the client-local state via <tt>s1'</tt> in the previous step, the precondition for conflict-resolution via <tt>coopt</tt>, i.e. divergence by a single operation, is met. <br />
<br />
''The important and central question is what other parameter is supposed to go into <tt>coopt</tt> with <tt>s2</tt>.''<br />
<br />
Considering that the server-state did not contain <tt>c</tt> when generating <tt>s2</tt>, <tt>c</tt> in some form resembles/relates to the deviating operation. With <tt>c'</tt> we are aware of a transformed version of operation <tt>c</tt>, which could be applied to an <tt>s1</tt> document state in an intention-preserving/non-destructive manner. Thus <tt>c'</tt> is to be the other parameter to be respected when transforming operation <tt>s2</tt> for applicability on the client side. [[Media:cola_shared_editing_statespace_divergence_by_more_than_one_op.png|Figure 5]] has concrete operations substituted for <tt>c, s1, and s2</tt>.<br />
<br />
{|border="1" cellpadding="3" cellspacing="0" align="center"<br />
|+''mapping for exemplary operations in Figure 5''<br />
|-<br />
! style="background:#efefef;" | <tt>c</tt><br />
! style="background:#efefef;" | <tt>c'</tt><br />
! style="background:#efefef;" | <tt>c' '</tt><br />
! style="background:#6495ed;" | <tt>s1</tt><br />
! style="background:#6495ed;" | <tt>s1'</tt><br />
! style="background:#ff8c00;" | <tt>s2</tt><br />
! style="background:#ff8c00;" | <tt>s2'</tt><br />
|-<br />
|del(5)||del(5)||del(5)||del(9)||del(8)||del(8)||del(7) <br />
|}<br />
<br />
Assuming that in state <tt>(0,2)</tt> the server receives the client-message originating from state <tt>(0,0)</tt> and communicating the client-operation <tt>c</tt> (i.e. <tt>del(5)</tt> in [[Media:cola_shared_editing_statespace_divergence_by_more_than_one_op.png|Figure 5]]), it becomes once again apparent, that an operational transformation via <tt>coopt(c,s2)</tt> won't suffice to reach consistent document states on client and server sides.<br />
<br />
The server, being in a document state off by more than one diverging operation considering the state on which <tt>c</tt> had been defined, some course of action is needed to transform <tt>c</tt> with respect to all operations, that have already been applied on the server state, i.e. regarding not only <tt>s2</tt>, but also <tt>s1</tt>.<br />
<br />
''obtaining an intention-preserving instance of operation <tt>c</tt> for application on state <tt>(0,2)</tt>''<br />
<pre><br />
coopt(c,s1)&rarr;(c',s1'); //use c' for transformation against s2<br />
&rArr; coopt(c',s2)&rarr;(c'',s2'); //c'' is OK for application on state (0,2)<br />
</pre><br />
''different notation for the same procedure''<br />
<pre><br />
applyLeftOfResult(coopt(leftOfResult(coopt(c,s1)&rarr;(c',s1')),s2) &rarr; (c'',s2'));<br />
</pre><br />
[[Media:cola_shared_editing_statespace_divergence_by_more_than_one_op_closure.png|Figure 6]] extends the editing scenario accordingly.<br />
=====the algorithm=====<br />
Having closely inspected an example where operational transformations cannot be utilized directly to resolve conflicting situations, we understand the need for an ''encapsulating'' algorithm, taking care of meeting the proper preconditions for the application of '''<tt>coopt</tt>'''.<br />
<br />
Interpreting the state-space graph in [[Media:cola_shared_editing_statespace_algorithm_client_perspective.png|Figure 7]] as how a client perceives an editing session and the processing of local and incoming operations, leads to the required functionality of the controlling ''concurrency algorithm''. From the client's perspective the server was last known to be in state <tt>(x,y)</tt>. The client state has moved on by <tt>k</tt> locally generated and executed operations since the last server-to-client communication. All <tt>k</tt> messages generated by the client have been communicated to the server, so that the next server-generated message is to originate from one of the states between <tt>(x,y)</tt> and <tt>(x+'''k''',y)</tt>. As demonstrated in the introductory example to this subsection, an incoming operation, originating from a state <tt>(x+'''i''',y)</tt>, where i &isin; {0,..,(k-1)}, could not be directly <tt>coopt</tt>'ed with the most recent client operation '''<tt>k</tt>'''. Instead the received server operation has to be consecutively <tt>coopt</tt>'ed with each operation starting with the one generated by the client on the same state as the server operation originated from, leading up to and including the state of operation <tt>k-1</tt>. That is each succeeding <tt>coopt</tt> is called with the result of the transformed server message from the preceding <tt>coopt</tt> and the respective state's local operation. The last <tt>coopt</tt>, which is '''<tt>coopt(i*, k)</tt>''', where ''i* := indicates properly transformed server message/operation i'', yields the intention-preserving transformed operation <tt>i^(*+1)</tt> applicable on the client state and taking it to state '''<tt>(x+k, y+1)</tt>'''. <br />
<br />
Since the ''cola'' architecture is designed to have the server only differ from the clients in that it serves as central notification instance, the algorithm also applies to the server site.<br />
<br />
<br />
<br />
==Integration into Eclipse Communication Framework==<br />
The '''org.eclipse.ecf.example.collab.editor''' plugin provides a [[Example_Shared_Text_Editor|shared editor]] implementation based on the [[Eclipse_Communication_Framework_Project|Eclipse Communication Framework]]. <br />
<br />
It differs from the ''cola'' approach in that it does not utilize advanced mechanisms, such as ''operational transformations'' and a ''concurrency algorithm'', to ensure consistency in document states at discrete sites while maintaining the effects of every editing operation.<br />
Instead of communicating atomic editing operations to each remote site, where state-specific transformations ensure consistent applicability, the [[Example_Shared_Text_Editor|exemplary shared editor]] sends the entire document content to session participants upon local application of an operation. The incoming document overwrites each receiver's copy. In case of communications ''crossing on the wire'', editing information is lost and document states divert.<br />
<br />
In order to maximize code reuse, ''cola's'' sample implementation, '''org.eclipse.ecf.example.sharededitor.cola''', builds on the prior [[Example_Shared_Text_Editor|shared editor]], modifying and extending its functionality as needed. Thus, once deployed and even though the core communications are handled very differently, setting up and running either editor is very much alike.<br />
<br />
===Take a Sip===<br />
====The Cola Source====<br />
''Cola's'' current incarnation lives in a CVS repository at the [http://osuosl.org/ Oregon State University Open Source Lab]. You can get your hands on the sourcecode via anonymous access.<br />
<pre><br />
:pserver:anonymous@ecf1.osuosl.org:/ecf/applications/org.eclipse.ecf.example.sharededitor.cola<br />
</pre><br />
<br />
====Set it Up & Get it Running====<br />
As for obtaining the rest of the code required to build and run ''cola'', consult the [http://www.eclipse.org/ecf/resources.html ECF development resources page] and get the latest sources. A ''team project set'' is provided to greatly simplify your workspace setup.<br />
<br />
Consult the straightforward [[Example_Shared_Text_Editor|how-to]] on the prior shared editor, selecting the ''cola''-specific menu entries at steps '''5.''' and '''7.''', to set up a ''cola'' editing session.<br />
<br />
''Cola'' is stable and functional apart from some minor restrictions, which are being worked on. Currently the following restrictions apply:<br />
*document sharing is limited to two sites<br />
*both participants have to join, prior to editing<br />
*multi-character operations, such as copy & paste of multiple characters or bulk deletion of such, are yet to be implemented.<br />
<br />
==Resources==<br />
===Meeting Notes=== <br />
*[[Eclipse_Communication_Framework_Project|ECF Conference Calls]]<br />
*[[Monday May 29, 2006]]<br />
<br />
===Papers & Books===<br />
*Beck, K 2005, ''Extreme Programming Explained - Embrace Change'', 2nd Ed., Addison-Wesley, Boston MA (USA), p. 42<br />
*Sun, C & Ellis, C 1998, [http://citeseer.ist.psu.edu/sun98operational.html ''Operational Transformation in Real-Time Group Editors: Issues, Algorithms, and Achievements''], Proceedings of the ACM Conference on Computer-Supported Cooperative Work, Seattle WA (USA), pp. 59-68<br />
*Nichols, D, Curtis, P, Dixon, M & Lamping, J 1995, [http://portal.acm.org/citation.cfm?coll=GUIDE&dl=GUIDE&id=215706 ''High-Latency, low-bandwidth windowing in the Jupiter collaboration system''], Proceedings of the 8th annual ACM symposium on User interface and software technology, Pittsburgh PA (USA), pp. 111-120</div>Codesurgeon.gmail.com