Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[buckminster-dev] Re: Buckminster Roadmap

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


Back to the top