[
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