[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [buckminster-dev] Re: Buckminster Roadmap
|
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