[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [buckminster-dev] Re: Buckminster Roadmap
|
Hi Thomas,
I understand your concern, but my view of the situation is based on the
realization that we are already on a native track, with the eclipse
launcher. I don't agree that a Java application can be considered a
drop-in replacement for eclipse.exe.
The enhancement request for eclipse.exe is out there since 2007, waiting
for someone to provide the effort. Regardless of the actual design
decisions, native code will have to change. I would prefer to see that
change in this bigger picture.
During the conversation on bugzilla, the concern was raised that network
sockets would be unacceptable for security reasons. The proliferation of
the use of sockets on desktop systems has already proven problematic:
some usual suspects, such as GTalk and Skype are known to hog ports,
causing other processes to fail during start-up. It's a problem I see
more and more in my development environment. A classic example is people
having problems with the RMI/JNDI ports of their local application server.
The background for the use case here is desktop integration and
operating system integration - areas where the Java platform is still
lagging behind. Even JDIC (Java Deskop Integration Components) is
basically a native extension to the Java platform, and before it came
bundled, you needed to manage the libraries yourself; and JDIC is what
it is.
In addition, OSGi provides excellent support for native libraries,
beyond what the Java platform provides.
The Eclipse framework already manages a set of native libraries, the
most obvious ones being SWT. There is an opportunity here to build on
that experience, as opposed to having to start from scratch.
A lot of work on Java IPC has already been done. Both in Java and native
code. Native IPC coding is not rocket science, on the contrary. While
the win32 code differs greatly from the *nixes, a lot of the latter
support the POSIX.4 interfaces.
I'm trying to solve many problems at once, by building on top of a Java
IPC library, which can be re-used standalone, and which can also be
bundled into Eclipse, in order to provide a dedicated communication
channel with the native launcher.
If we wouldn't be pushing the envelope in this community, a lot of
things we value today, simply wouldn't be available in the Eclipse
ecosystem (which has a large native developer base, b.t.w.).
Best regards,
Dann
Thomas Hallgren wrote:
Hi Scott, Dann, Henrik,
There's one little detail here that nags me. We discuss a way to start
an executable by suffix registration or similar. Perhaps some IPC needs
to be involved in order to make that happen, perhaps not. What I am very
certain of is that the performance aspect of an potential IPC solution
must have a very low priority. It's only one call right? Or perhaps 3 at
the most.
I'm concerned that the "write once, run everywhere" paradigm of Java
gets sacrificed for no apparent reason here and I don't really see the
problem that originated this discussion as being an opportunity to
implement any of the non-java technologies that are mentioned. I'm not
saying that they shouldn't be implemented, I'm just pointing out that
for this particular case, no such thing is needed.
Regards,
Thomas Hallgren
Dann Martens wrote:
Hi Scott,
On the contrary, your 'due diligence' is greatly appreciated!
As an Eclipse aficionado, I can assure you Buckminster is part of your
community. As you are part of mine.
The Eclipse community.
Best regards,
Dann
Scott Lewis wrote:
Hi Dann,
Dann Martens wrote:
Hi Scott,
I wouldn't worry too much about ECF being left out. I can assure you
that it will not: I think IPC belongs in ECF, one way or another.
Any work I'll do on that front, I will offer as a contribution to
ECF. I've already discussed this with you on the ECF newsgroup, as I
am well aware of the mission statement behind ECF.
However, there is one thing I hope you would agree on: the core IPC
library will *not* have ECF abstractions. There should be another
layer for that. At the lowest layer, there will be the classical
Java I/O primitives, as we all know from java.io and java.nio. My
starting point for this layer is the source code available at:
http://sourceforge.net/projects/clipc (@author Clark N. Hobbie);
I really think there is an opportunity to implement:
Named Pipes
Semaphores
Domain Sockets (Thomas loves these!)
Shared Memory
Signals
Interestingly enough, the named pipe equivalent on the win32
platform is in actuality almost (or completely) a domain socket.
There will be a pure Java bundle
org.eclipse.-.ipc
and native fragments for all the supported platforms, e.g.
org.eclipse.-.ipc.win32.x86
The example you propose, IPC underneath the remote services API is an
example of this layering, or do you see this differently?
No, I agree completely. I expect the layering to be something like:
Client Code
RFC 119 Impl
ECF Remote Services API Provider/Impl
<your api/IPC>
Shared memory
So I wouldn't expect the IPC layer to have dependencies on ECF
abstractions...rather the ECF provider would have dependencies on
your API (and ECF abstractions).
Sorry buckminster community for diversion...Dann can move over to
ecf-dev if more specifics are desired.
Scott
