|
| Re: roadmap questions [message #603948 is a reply to message #603946] |
Wed, 24 May 2006 02:25   |
 Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hi Bill,
Bill Joy wrote:
> I have been looking at the recently added wiki which lists the "four new
> initiatives" for ECF during this year.
>
> One of things I found interesting about Eclipse 3.2 is IFileStore. I was
> surprised that ECF does not make use of this in the recently added file
> sharing example. Are there some technical reasons why not?
No.
>Will ECF make
> use of IFileStore to implement access to a remote filesystem for sharing
> files or even projects?
Yes. One thing that ECF may add to the IFileStore API at the API level
is *asynchronous* sharing of virtual files/resources/projects/folders
(like the KIO API e.g.
http://www.usenix.org/events/usenix2000/freenix/full_papers/ perazzoli/perazzoli_html/node7.html).
But we fully anticipate using/taking advantage of the EFS (Eclipse File
System) work also. It's really nice stuff.
>
> It looks like the current implementation of file sharing does total content
> replacement when updating. Is this example going to evolve to more
> sophisicated collaborative editing?
I'm not sure if the file sharing will evolve to more sophisticated
collaborative editing...or whether our existing collaborative editor
example (org.eclipse.ecf.example.collab.editor) will migrate toward
sharing whole files. But I think the answer to your general question is
'yes'...we would like to support a range of strategies for distributing
state changes...file level, model state changes within editors (e.g.
adding/removing text).
>
> What is "application sharing"? Currently there seems to be no information
> there since it leads to a login request. (Is this the ability to remotely
> control an application by re-hosting its UI? How do you intend to do that?)
Yes. I would like to see using the VNC protocol to sharing UI contents
as images (in point to point and multipoint) and using remote keyboard
and mouse input to drive a local application (as VNC does). In keeping
with the ECF approach, I think it would make sense to define an API for
application sharing, and then pair with that an implementation based
upon VNC specifically (but leave open the possibility that other app
sharing protocols can/would be used via other ECF providers).
>
> The old road map had "team debugging" listed as a feature for this
> timeframe. Is any part of "application sharing" applicable to this?
>
Ideally it would be desirable to do application sharing at the level of
individual views within Eclipse...and share debugger views (or
perspectives perhaps) to provide some semblance of team debugging.
But this isn't the orginal intent of 'team debugging' ideas. Rather I
would like to see collecting information about a running process via the
Eclipse debug API, and then distributing the process state changes to
remotes events via ECF. As it turns out, we are talking right now with
a student interested in doing a distributed debugger for the Google
Summer of Code and would like to support this project with ECF-based
messaging.
And, we would like to work with other community members on any/all of
these areas...file/workspace sharing, app sharing, and distributed
debugging if some of you have the means to contribute to ECF. We just
have limited capacity to work on all of them at once...but I'm working
to address that as well.
I'll try to add elements of this discussion to the wiki plans pages.
Thanks,
Scott
|
|
|
| Re: roadmap questions [message #603954 is a reply to message #603948] |
Wed, 24 May 2006 03:25 |
Bill Joy
Messages: 60
Registered: July 2009 |
Member |
|
|
Thanks, Scott.
I can certainly appreciate having limited bandwidth (which is one reason why
I would like to leverage your work and those of the other ECF committers).
Are there any specific goals which your team expects to accomplish in the
next couple of months? Or if it is an easier question, is progress on any
of the new initiatives going to be happen sooner than the others?
"Scott Lewis" <slewis@composent.com> wrote in message
news:4473C42C.3080803@composent.com...
> Hi Bill,
>
> Bill Joy wrote:
>> I have been looking at the recently added wiki which lists the "four new
>> initiatives" for ECF during this year.
>>
>> One of things I found interesting about Eclipse 3.2 is IFileStore. I was
>> surprised that ECF does not make use of this in the recently added file
>> sharing example. Are there some technical reasons why not?
>
> No.
>
>>Will ECF make use of IFileStore to implement access to a remote filesystem
>>for sharing files or even projects?
>
> Yes. One thing that ECF may add to the IFileStore API at the API level is
> *asynchronous* sharing of virtual files/resources/projects/folders (like
> the KIO API e.g.
> http://www.usenix.org/events/usenix2000/freenix/full_papers/ perazzoli/perazzoli_html/node7.html).
>
> But we fully anticipate using/taking advantage of the EFS (Eclipse File
> System) work also. It's really nice stuff.
>
>>
>> It looks like the current implementation of file sharing does total
>> content replacement when updating. Is this example going to evolve to
>> more sophisicated collaborative editing?
>
> I'm not sure if the file sharing will evolve to more sophisticated
> collaborative editing...or whether our existing collaborative editor
> example (org.eclipse.ecf.example.collab.editor) will migrate toward
> sharing whole files. But I think the answer to your general question is
> 'yes'...we would like to support a range of strategies for distributing
> state changes...file level, model state changes within editors (e.g.
> adding/removing text).
>
>>
>> What is "application sharing"? Currently there seems to be no
>> information there since it leads to a login request. (Is this the
>> ability to remotely control an application by re-hosting its UI? How do
>> you intend to do that?)
>
> Yes. I would like to see using the VNC protocol to sharing UI contents as
> images (in point to point and multipoint) and using remote keyboard and
> mouse input to drive a local application (as VNC does). In keeping with
> the ECF approach, I think it would make sense to define an API for
> application sharing, and then pair with that an implementation based upon
> VNC specifically (but leave open the possibility that other app sharing
> protocols can/would be used via other ECF providers).
>
>>
>> The old road map had "team debugging" listed as a feature for this
>> timeframe. Is any part of "application sharing" applicable to this?
>
> Ideally it would be desirable to do application sharing at the level of
> individual views within Eclipse...and share debugger views (or
> perspectives perhaps) to provide some semblance of team debugging.
>
> But this isn't the orginal intent of 'team debugging' ideas. Rather I
> would like to see collecting information about a running process via the
> Eclipse debug API, and then distributing the process state changes to
> remotes events via ECF. As it turns out, we are talking right now with a
> student interested in doing a distributed debugger for the Google Summer
> of Code and would like to support this project with ECF-based messaging.
>
> And, we would like to work with other community members on any/all of
> these areas...file/workspace sharing, app sharing, and distributed
> debugging if some of you have the means to contribute to ECF. We just
> have limited capacity to work on all of them at once...but I'm working to
> address that as well.
>
> I'll try to add elements of this discussion to the wiki plans pages.
>
> Thanks,
>
> Scott
|
|
|
| Re: roadmap questions [message #603963 is a reply to message #603954] |
Wed, 24 May 2006 04:21 |
Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hi Bill,
> I can certainly appreciate having limited bandwidth (which is one reason why
> I would like to leverage your work and those of the other ECF committers).
>
> Are there any specific goals which your team expects to accomplish in the
> next couple of months? Or if it is an easier question, is progress on any
> of the new initiatives going to be happen sooner than the others?
I think the work on the VOIP interfaces will move forward.
The collaborative editing and shared workspaces ideas will also move
forward. For example, the (new) Corona project is using ECF to build
some shared workspaces tooling (i.e. sharing IResources).
There probably will be work on the file sharing APIs and implementations
as well. For example, another Google Summer of Code project is to
extend the ECF filesharing apis and build a BitTorrent provider to
implement that API.
I would really like to immediately work on VNC-based application sharing
and distributed debugging, but ECF is approaching 1.0 release so we have
to finalize APIs, get all our ducks in a row for release review, work on
further documentation, etc.
And if there are folks (like yourself) who would be able to work with us
on defining and implementing some of these incomplete ECF 'extension'
APIs (e.g. file sharing, app sharing, distributed debugging) then it's
not at all required that committers perform all that work. If people
can contribute designs and/or implementations under EPL, then those
could be provided by interested community members.
Scott
>
>
>
> "Scott Lewis" <slewis@composent.com> wrote in message
> news:4473C42C.3080803@composent.com...
>> Hi Bill,
>>
>> Bill Joy wrote:
>>> I have been looking at the recently added wiki which lists the "four new
>>> initiatives" for ECF during this year.
>>>
>>> One of things I found interesting about Eclipse 3.2 is IFileStore. I was
>>> surprised that ECF does not make use of this in the recently added file
>>> sharing example. Are there some technical reasons why not?
>> No.
>>
>>> Will ECF make use of IFileStore to implement access to a remote filesystem
>>> for sharing files or even projects?
>> Yes. One thing that ECF may add to the IFileStore API at the API level is
>> *asynchronous* sharing of virtual files/resources/projects/folders (like
>> the KIO API e.g.
>> http://www.usenix.org/events/usenix2000/freenix/full_papers/ perazzoli/perazzoli_html/node7.html).
>>
>> But we fully anticipate using/taking advantage of the EFS (Eclipse File
>> System) work also. It's really nice stuff.
>>
>>> It looks like the current implementation of file sharing does total
>>> content replacement when updating. Is this example going to evolve to
>>> more sophisicated collaborative editing?
>> I'm not sure if the file sharing will evolve to more sophisticated
>> collaborative editing...or whether our existing collaborative editor
>> example (org.eclipse.ecf.example.collab.editor) will migrate toward
>> sharing whole files. But I think the answer to your general question is
>> 'yes'...we would like to support a range of strategies for distributing
>> state changes...file level, model state changes within editors (e.g.
>> adding/removing text).
>>
>>> What is "application sharing"? Currently there seems to be no
>>> information there since it leads to a login request. (Is this the
>>> ability to remotely control an application by re-hosting its UI? How do
>>> you intend to do that?)
>> Yes. I would like to see using the VNC protocol to sharing UI contents as
>> images (in point to point and multipoint) and using remote keyboard and
>> mouse input to drive a local application (as VNC does). In keeping with
>> the ECF approach, I think it would make sense to define an API for
>> application sharing, and then pair with that an implementation based upon
>> VNC specifically (but leave open the possibility that other app sharing
>> protocols can/would be used via other ECF providers).
>>
>>> The old road map had "team debugging" listed as a feature for this
>>> timeframe. Is any part of "application sharing" applicable to this?
>> Ideally it would be desirable to do application sharing at the level of
>> individual views within Eclipse...and share debugger views (or
>> perspectives perhaps) to provide some semblance of team debugging.
>>
>> But this isn't the orginal intent of 'team debugging' ideas. Rather I
>> would like to see collecting information about a running process via the
>> Eclipse debug API, and then distributing the process state changes to
>> remotes events via ECF. As it turns out, we are talking right now with a
>> student interested in doing a distributed debugger for the Google Summer
>> of Code and would like to support this project with ECF-based messaging.
>>
>> And, we would like to work with other community members on any/all of
>> these areas...file/workspace sharing, app sharing, and distributed
>> debugging if some of you have the means to contribute to ECF. We just
>> have limited capacity to work on all of them at once...but I'm working to
>> address that as well.
>>
>> I'll try to add elements of this discussion to the wiki plans pages.
>>
>> Thanks,
>>
>> Scott
>
>
|
|
|
Powered by
FUDForum. Page generated in 0.01797 seconds
] 
Search
Help
Register
Login
Home
