Pallet...?

[Randall Wood]

On 7 Nov 2007, at 13:34, Juan Manuel Palacios wrote:

>
> On Nov 7, 2007, at 11:23 AM, Randall Wood wrote:
>
>> On Tuesday, November 06, 2007, at 01:36PM, "Juan Manuel Palacios"  
>> <jmpp at macports.org> wrote:

[snip]

>> I'm tying into the MacPorts API, although if I can get significant  
>> performance improvements by not using the API, I might rewrite in  
>> Cocoa. (For example, until I began using MPPort objects that each  
>> made a call against the MacPorts API when initialized, a pure  
>> Cocoa method to read the PortIndex was noticeably faster than  
>> using the MacPorts API--however it turns out that I lost all those  
>> advantages when I wrote the MPPort objects. I'm thinking of  
>> rewriting them to make any and all calls against the API lazily  
>> (i.e.: only when absolutely required), but I am also aware that  
>> the MPIndex needs to figure out the URI to the portfile for an  
>> MPPort and pass that in.
>
>
> 	Rewriting MacPorts in any language up to any extent is a major,  
> long term endeavor that would naturally spark off a lot of  
> brainstorming around it:

The only process that I am (re)writing is getting a list of all ports  
(return [mportsearch]) since it is reportedly significantly faster to  
parse all of a user's PortIndex files into an NSDictionary than to  
use the MacPorts Tcl API to do so.

> -) first and foremost, what language?? (/me phears the holly wars!)

The Framework is being written to support Cocoa/Objective C GUI  
programs on Mac OS X, so its in Cocoa/Objective C. Although in a  
private email, someone did ask if I knew of a Python API for MacPorts.

> -) once that's settled, do we start from scratch with a new design  
> or, on the other hand, try to re-implement the existing one in the  
> new language?

I am a firm believer in object orientation, so my Framework does not  
provide a function-to-function mapping of the Tcl API as sometimes it  
just hasn't made sense to do things that way in an object oriented  
Framework.

> -) barring that, how would our new APIs look like?
> -) and last in this very short list (which could easily be  
> expanded), but certainly by no means least, what do we do to *NOT*  
> loose all the work already invested in our Portfiles?
>
> 	Now, I'm not trying to discourage you in any way.... in fact, I'm  
> more than sure many here would put together a party if we embark on  
> a rewriting endeavor (probably even including me ;-) -- and, in  
> fact, when Landon once considered it, Cocoa was a very strong  
> option -- I am instead asking you to please be most open about it  
> if you are indeed considering a full rewrite of base, as otherwise  
> a solitary effort may result in massive waste of time and resources.

I don't want the work either.

> ---snip---
>
>> I am very close (planning on starting this weekend) on rewriting  
>> the MacPorts Notifier (its distributed via MacPorts) to use the  
>> Framework for syncing and then for upgrading ports and once I am  
>> satisfied that the Framework is usable in a real-world scenario,  
>> in getting it officially into the project and versioning and  
>> bundling it for distribution.
>
> 	If your framework does stand up to the test of a real world  
> application we could of course brainstorm over distributing it as a  
> Cocoa glue for Mac OS X native GUIs for MacPorts. I believe that  
> would be a very interesting project to explore! Can you please let  
> us know of your progress when you reach any milestones?

My only real concern is how do we ensure that we can push the GUI  
through our systems? Every single GUI that I've seen mentioned on the  
lists is closed and we can't redistribute through MacPorts (or worse  
the GUI uses some other mechanism to self update).

>> Maybe I should just document all this on Trac...
>
> 	That would be sweet!
>
>>
>> --
>> Randall Wood
>> rhwood at mac.com
>
>
> 	Kudos for the hard work and energy devoted to the project!  
> Regards,...
>
>
> -jmpp
>
> PS: And sorry again for the Randall/Ryan confusion ;-)
>



Randall Wood
rhwood at mac.com
http://shyramblings.blogspot.com

"The rules are simple: The ball is round. The game lasts 90 minutes.  
All the
rest is just philosophy."