Paul Guyot wrote:
> =C0 (At) 8:16 -0500 27/01/02, mark d smith <markds_at_mac.com> =E9crivait
> (wrote) :
>> Thanks for all the info Paul. I'm relativelay new to Newton (1.5
>> years) so until now I didn't really understand the problems involved
>> in writing an "NCU-like client" for MacOS X.
> NCU plays the server, BTW.
Yes, of course.
>> I tried the UnixNPI route but couldn't make/compile the executable
>> from the download. (Aside, a tip on this would be great. I keep
>> getting an error about gcc (can't remember what exactly)) (I've got
>> a symlink to my USBSerial adapter at /dev/newton
>> (/dev/tty.keyUSA19181.1) so I think it will work if I can get it to
>> build.)
>>
>> The things is...
>>
>> ...if UnixNPI works and there are so many problems with a "carbon
>> version of NCU", why not make a Cocoa interface for UnixNPI and maybe
>> work on extending the functionality ?
> Well, here are some reasons.
> * First, UnixNPI is currently 669 lines of code
> (newtmnp.c 439
> newtmnp.h 25
> unixnpi.c 205)
> which is sufficient for MNP Serial-only load package operation.
>
> The DCL was 12 K lines last time I counted. It's not a big project,
> but nevertheless, you have some work to provide before you could do a
> backup as the DCL provides it. So I think that "extending the
> functionality" is not a 10 minutes operation.
>
> * Second (the answer to why not merge both projects)
> UnixNPI is released under the GPL
> The DCL is to be released under the Reflexive License.
> They are copy-left but incompatible licenses.
>
> I won't discuss once again against the GPL, just let me summarize: I
> don't like the GPL, I don't like the GNU project, I don't like
> software that are hard to compile or a supposedly supported target
> (apparently, you seem to enjoy it as well), and I don't like to waste
> my time with poorly written code or documentation. Since nobody pays
> me for it or forces me to do it (unlike using WFC in the university),
> I won't work on any GPL project. Since I spent time to draft an open
> source license which imposes some stuff that I find essential (such
> as a documentation or basic comments), the open source project I
> start will be released under it when possible.
>
> * Third, when I say that AppleTalk (well, ADSP) isn't apparently
> possible under OpenSTEP, I don't mean within Carbon. It's not
> possible with any language/framework except in the MacOS emulator
> (Classic). A cocoa project won't help either.
>
> The only thing that UnixNPI does and that the DCL doesn't is MNP
> compression (without the Communication ToolBox). I mean, the only
> important thing. I have contacted Philz to ask him if he could
> release his code (which is in UnixNPI) under a reflexive-compatible
> license. (he apparently re-appeared in December). If he doesn't
> answer, I'll use some public domain x86 assembler code for DOS I
> found on the web to implement my own MNP compression stuff (I haven't
> been able to find any decent documentation I could work from, any
> hint is welcome), and then UnixNPI's only interest would be to be
> GPL'd, C only (the DCL is written in C++) and small.
I'm not going to argue with you Paul. LIke I said, I am really a novice=20
in all this. I also don'>t wnat you to think that I am in any way=20
unappreciative of your efforts. Quite the contrary. I am extremely=20
interested in this project because NCU is the only thing I really=20
"need" now which is not OS X native.=20
I do realise that turning unixNPI into an objective-C or java version=20
of NCU is unrealistic.=20
If I understand you correctly, one of the main reasons why a very=20
simple (OK, I should say very basic not very simple) "Cocoa wrapper"=20
for UnixNPI is not so straightforward is the conflict of the licenses.=20
Maybe this is resolvable, maybe not.=20
On the technical side, it may even be possible to do something in=20
AppleScript Studio which just puts a nice interface on the UnixNPI=20
command line tool. That would be a start. If UnixNPI works via the=20
Terminal in MacOS X and Sloup on the Newt as far as backups, package=20
installation and transfer of text files over a serial port is concerned=20
(and although I haven't got it working yet - yes, you are right, I=20
don't like these games - I believe it does!), then an AppleScript=20
Studio interface _should_ be at least possible.=20
Easy for me to say in my relative ignorance. What do folks think ?
mark.
-- This is the Newtontalk mailinglist - http://www.newtontalk.net To unsubscribe or manage: visit the above link or mailto:newtontalk-request_at_newtontalk.net?Subject=unsubscribe
This archive was generated by hypermail 2.1.2 : Fri Feb 01 2002 - 16:03:18 EST