[Pythonmac-SIG] [FWD] OSABase

[has]

Jack Jansen wrote:

>>The license scenario looks bad.  You can't even download it without 
>>emailing him and saying "yes I comply with this license".  We'd 
>>probably be better off starting from scratch unless you can 
>>convince him to make his stuff open source under a PSF compatible 
>>license.
>
>Yes, very bad. Weird, too: this reference to " Because of issues 
>pertaining to registering OSA components with the MacOS, you may not 
>redistribute products derived from the personal edition of TextOSA. 
>" has me a bit worried. Would there really be something behind this, 
>or would it just be a smokescreen?

I've no idea myself, I'm afraid, though I've appended his response on 
the MacScrpt mailing list to the end of this mail FWIW.

I know you guys have more than enough on your own plate, but I think 
it's something that really has to fall in your court rather than 
mine. Like I've said before, I have neither the C knowledge and 
familiarity with MacPython's guts nor the authority and political 
clout to make any kind of call on this subject. That's why I'm 
tossing it in you guys' direction, because you're the ones that can. 
Anyway, best thing would be to go talk to Philip; he's a nice guy and 
I'm sure he won't bite if you explain to him your needs and what your 
concerns are, and ask what the chances are he could/might adjust his 
position to something more statisfactory.


>>There is approximately no chance whatsoever of OSA component 
>>support making it into Python 2.4.  The first alpha is almost out 
>>the door, and there isn't even a prototype or PEP that detains the 
>>whys and hows.  It would be great if we had it, but it won't be a 
>>standard feature until Python 2.5 at the earliest.
>
>I beg to differ. As far as I can see, the component is completely 
>separate from the distribution. It would use the framework from the 
>distribution, but that's about it. There's no reason it couldn't be 
>grafted onto the current 2.3 distribution on Panther. The only 
>problem is: someone has to do the work:-)

I think you're right on this. Please don't quote me on this, but I 
think how it works is that you create a scripting component, 
/Library/Components/Python.component, and this component would link 
(presumably dynamically) to whatever MacPython.framework you've got 
installed on your system. Philip's wrapper should make this hook-up 
easier than if you do it yourself through Apple's original OSA API, 
though _how_much_ easier I couldn't say myself, obviously. But maybe 
it'll turn out to be really trivial for somebody with a bit of C and 
MacPython API experience - only one way to find out, of course. ;)

As for who gets to do the work... um, Very busy. Very, very busy. 
Maybe in another five to ten years, once I've finally bought myself a 
clue as to what I'm doing. Meantime, feel free to donate dollars any 
time you like, yes? <g>

Cheers,

has

-------

Date:    Mon, 31 May 2004 13:49:17 -0700
From:    Philip Aker <philip at VCN.BC.CA>
Subject: Re. OSABase

Hi Hamish,


>>  You, or more likely Hamish, can implement Python as an OSA language
>>  using OSABase. Then it can be available to you in any OS X
>>  application supporting scripting calls.

>  Heh, not me squire; have you seen any of my attempts at C? ;p

I did pick up the latest and greatest and noticed a few C modules. So
that's a big step up from the previous zero quantity. With people like
c.nebel contributing, I'd guess that such attempts would be quite good.


>  Anyway, Jack Jansen and/or Donovan Preston were/are the ones
>  supposedly(?) working on OSA support for Python. (I rather regret not
>  trying harder to get you folks together at the time, but don't have
>  very much traction in the MacPython community unfortunately.)

I had this stuff 99.99% completed last January but had some gigs to
take care of plus I squished a disk in my lower back and kinda forgot
about everything else for nearly two months.


>  Took a quick squizz at your page, though wondering what are the
>  licensing conditions/restrictions you mention? (Python uses a very
>  liberal open-source license.)

Almost none. Components must have a couple of four char codes
registered with Apple. This prevent idiots from re-distributing TextOSA
with a customized driver file. For Python, since I'm not really a
member of that community, I'd suggest a real Pythonite select and
register the four char codes and fill in the other details. I get the
impression that you may wish to have separate info for both python and
pythonw. Also, you'll probably want to work with the C/C++ interfaces
to grab every last bit of speed but that is not necessary for an
implementation. It's perfectly feasible to do them with 'do shell
script' AppleScript for the nonce and upgrade to C/C++/Objective-C
later. The C interfaces are easy to grok for someone vaguely familiar
with AEDescs and a really simple callback notion (to initialize the
component). Also, I test for NULL procs so only handling 'execute' is
still make for a legit component.

-- 
http://freespace.virgin.net/hamish.sanderson/