JXTA for ObjC (was: Re: a simple program)

[Aurelien]

Richard, Thank you very much. Now I think I understand that Objective-C 
is no real replacement for C, but an extension of C in the first place, 
so for example GUI programming can be done more smoothly. For system 
programming, you're still bound to using plain C, or a mix of objc and C.

I'd like to share thoughts about the pros and cons of an objc binding 
for the JXTA platform.

JXTA is a p2p platform meant to provide a common ground for all kinds of 
existing and future p2p software. It offers a shell and a GUI and, as of 
now, is strictly written in Java. Basically though, JXTA is only a 
specification and fundamentally cross-platform. A C binding is now being 
written.

I think JXTA is groundbreaking, because it finally provides a 
specification for cross-platform distributed computing.

Why JXTA for ObjC ? Because JXTA for Java is really Jini and this is 
precisely what JXTA was all about. Distributed computing for Java is 
nice but Jini (let alone Java) is Sun-proprietary, and Java's slow on 
small devices. Furthermore, Java GUIs are still (and I think this is 
never going to change) considerably less responsive than native GUIs.

Now JXTA for ObjC pros:

- ObjC/GNUStep are free and open;
- ObjC is arguably faster than Java;
- ObjC GUIs are native;
- ObjC provides a dynamic code loading mechanism, through the use of 
NSBundle;

I would like confirmation on the following assumptions about ObjC:

- It is possible to make Obj-C GUIs have the look-and-feel of all 
existing platform (perhaps by using QT in the back-end);
- ObjC can be ported to handheld devices;

As a potential side-effect, JXTA could be a pervasive tool in favor to a 
more widespread use of Obj-C/GnuStep.

Cheers,

Aurélien

Le vendredi 17 août 2001, à 08:36, Richard Frith-Macdonald a écrit :

> On Thursday, August 16, 2001, at 09:19 PM, Aurelien wrote:
>
> > > First ... you can do GNUstep coding in Java if you want ... we have a 
> > > Java interface which works
> > > very well and lets you use ObjC classes from Java code and vice versa.
> >
> > Tried that on Mac OS X. Never again !
>
> Ok ... but it works well for me with GNUstep.  Our company uses Java 
> servlets as a front end to an ObjC system.
>
> > I was trying to compile your program right into Apple's Project 
> > Builder, which is supposed to be possible, or not ?
>
> No ... you asked for GNUstep code, and I wrote GNUstep specific 
> stuff ... in MacOS-X you must use standard C socket
> code to create the listening socket, than turn that into a file handle, 
> in GNUstep there is a method that does that
> all for you.
>
> > Why the RELEASE(self) type macros ? - which do not compile - instead 
> > of the standard [self release]
>
> Under GNUstep you have the option of building the system with garbage 
> collection ... in which case the macros stop
> the reference counting code from being compiled at all.
>
> > The [NSFileHandle fileHandleAsServerAtAddress: nil service: @"6401" 
> > protocol: @"tcp"] doesn't exist in Mac OS world. Is there a 
> > Cocoa-savvy replacement you know about ? (I'm not sure I understand 
> > the API docs sufficiently)
>
> No ... they use the C socket() and listen() calls instead.
>
> > Hem, I also have a further concern: this fileHandle thing doesn't 
> > sound very network oriented... Mmh, now how do you do datagram 
> > networking. :-) (yerk! yerk! -> that was my coming second question to 
> > this mailing-list !)
>
> No ... it's a class cluster so you can create your own concrete 
> subclasses for special purposes.  I kind of meant to add
> UDP support to GNUstep (that's what the 'protocol' argument is for), 
> but haven't got round to it.  It would be pretty
> easy for a C programmer to do though.