Il giorno 23/mar/08, alle ore 09:11, Jordan K. Hubbard ha scritto:
All of the scenarios could just as easily be satisfied by another Cocoa port front-end that does the Growl notifications and the UI and everything else you've described. Such an application could also use the existing port(1) infrastructure directly, no
Thanks for your answer Jordan, hearing your opinion is very important to me. You are right, a classical Cocoa app would solve some of the basic tasks I mentioned, if all that we want is having MacPorts being used by one (experienced) user:); but this would lead to some major challenge once someone will want to setup another client, perhaps a web-based one or a Java-based one (it's just an example:)): he shall write from scratch the entire lower layers of his app to make it work the way he wants, dealing with permissions as well (Task 7). No word about cuncurrent MacPorts running on the same system or the fact that a solution of this kind would be future-proof, in case MacPorts evolved. Generally speaking Task 5 ("GUI") would be easily addressed with an upper layer to manage MacPorts Core. One of the reasons for all this is to make MacPorts easy and affordable even to "naive users" with the help of third party developers who could count on an efficient and no trouble way to use the local MacPorts installation. As you can see I'm speaking quite generally without touching any techincal issue in detail, so I'd really be happy to hear more of your opinions, "just in case".:) Anyway thank you and don't be concerned, I really appreciate direct approaches.:) -- // Et quid amabo nisi quod rerum enigma est?