[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [buckminster-dev] Re: Buckminster Roadmap
|
Hi All,
<lurker materializes>
I'm not sure if this is relevant...and apologies to list members if this
is outside of scope (as I'm not completely clear on all of what Dann is
doing), but FWIW we (ECF project) have recently had some folks express
interest in creating a shared memory implementation of ECF's remote
services API. The intention here is that with ECF's provider
architecture, this allows a variety of IPC mechanisms to be used
underneath...and all end up exposing both synchronous (i.e. normal
method call/return) and asynchronous methods (via ECF's IRemoteService
interface) of accessing methods.
In any event, we are also preparing to release our implementation of
draft spec rfc119 (distributed osgi):
http://wiki.eclipse.org/Getting_Started_with_ECF%27s_RFC119_Implementation
Scott
ECF Remote Service API docs: http://wiki.eclipse.org/ECF_API_Docs
Dann Martens wrote:
Hi Henrik,
Henrik Lindberg wrote:
Hi Dann and Thomas,
A very interesting discussion, and raises issues regarding features I
also wanted for a long time (clicking on .java, .cspec, etc. to fire
up Eclipse or kick an editor).
When this has been discussed in the past, it has always come up
against the issue that there is reluctance to have the standard IDE
be directed from the outside for security reasons - and then the
initiative has died. The discussions have ended with - those that
want this can always install something that does this. And to me that
is exactly the problem - you have to have it there from the start to
make it useful.
I'm on the barricades for that one - @see
https://bugs.eclipse.org/bugs/show_bug.cgi?id=178927
Technically, recent reports on IPC-alike communications schemes
implemented in Java seem to promise a secure solution. Check out the
promising work of Clark N. Hobbie in
http://www.slideshare.net/ltsllc/java-ipc-and-the-clip-library - make
sure you take a look at his SharedMemory implementation.
Maybe there are different times now - and well worth trying again. It
should be possible to make the IDE have an API (via whatever
communication channel the two of you will come up with over that beer
:) you were talking about), and make it secure.
I doubt it. Yet, the thing is never to give up, even when it appears
to be an uphill battle.
"If You Can't Go Over or Under, Go Round."
BTW, really glad buckminster is working out fine for your team - and
really love to learn more about the things you have in the "Fuller"
package.
It has been an epiphany. One of the things you learn, once you achieve
this level of operating ease, is how other components start to show
their limitations. In our case, the typical request-response cascade
during a conversation with subversion, over a high latency (500ms -
4000ms) network from India to Europe, proved a major bottleneck.
Our vision has always been to support the "one click to get it all" -
the source, the tools, the runtime, the tests, etc. As well as being
able to do it all locally in your client the same way as when it runs
headless on the servers.
Agree that we could provide a better user experience regarding the
flow in the UI. Spaces project was one such initiative (convenient
publishing), now we worked on easier publishing to p2 repositories
(including build, pack, sign, and repo publishing). The UI is still
behind though. A lot of effort has gone into the p2 transition - and
when doing so, we have put in a lot of effort into p2 itself as we
all need it to have good quality.
That's a sensitive point you're touching there (no p2 pun intended).
From my experience, a proper UI lowers the learning curve
significantly. Imagine the PDE without the Manifest editor. Instead,
you would be forced to edit the MANIFEST.MF directly, or the
plugin.xml directly, using some elaborate specification. Check Eclipse
1.0 - the Plug-in Manifest Editor shipped out of the box. It would
have hampered adoption significantly, if it hadn't.
A neat thing with p2 is that it is possible to install things into an
environment from an external agent - still need to find the profiles
and p2 data areas to use though. One thing lacking there is the
central point that would list all such locations thus enabling to
show a user a list of what is installed.
An alternative - that I have used is to do tricks with the internal
browser in Eclipse - getting it to recognize things like ".cquery"
and running them within the IDE. I would really love to do that from
the outside as well... We used RSS OWL to do these tricks as they
done a lot of work on the internal browser - we have some really cool
things in the Buckminster RSS OWL integration regarding RSS feeds,
where the feeds have .cquery links in them. We have not been able to
do as much work in this area as we would like to - the p2 work took
most of our bandwidth.
That sounds pretty cool; perhaps an even better alternative for the
'Radar' view (which relied on a proprietary XML dialect).
Anyway, looking forward to continuing the discussion how to make
things really easy for developers/teams to get all the bits where
they are supposed to be...
Regards
- henrik
Best regards,
Dann
_______________________________________________
buckminster-dev mailing list
buckminster-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/buckminster-dev