On Mar 23, 2008, at 11:34 AM, Michelangelo De Simone wrote:

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.

OK, so, let's take your points on order:

1. A Cocoa app would actually be aimed at the inexperienced user, not the experienced one, so I'm not sure I see your point. It's also an unquestionable fact that 99.9% of all Macs are single user (even on an XServe sitting in a rack somewhere, it's a single admin configuring it to provide services to multiple people) so there's no need to add per-user ACLs or have per-user interfaces.

2. Your raise the issue of multiple types of clients (Cocoa, web, etc) and that's a fair one, particularly if the ports collection on a given machine is going to need to be administered both locally and remotely, but that's more of an argument for making the existing set of port(1) APIs more robust and/or complete than adding an additional layer. In other words, if we really want to support multiple interfaces (and writing a web interface is a very different challenge, with different constraints, than a Cocoa UI) then I think the right approach isn't to create a complex interpositioning layer with a daemon managing the collection, the right approach is to provide the right port APIs for making the creation of such alternative UIs easier and more straight-forward.

I also say this because the existing Tcl / C APIs for MacPorts were designed with this kind of thing very much in mind (the ui_foo APIs, for example, are implemented as abstractions for just this reason), though their evolution may not be (and probably is not) complete. The shortest distance between where we are and where you want to go would, therefore, seem to be to enhance what we have rather than create another layer. Again, MacPorts is already architected with embedding / external management in mind, so the question would be more one of "how can I make it do what I want" vs "how can I create another management layer."

I also really don't want you to read all this as "they don't like my ideas!" or "clearly they do not see how another indirection layer could be useful", since I think we DO like your ideas and, with our academic researcher hats on, can always see the potential application for another abstraction layer (dozens of such layers can, in fact, be easily imagined if you put your mind to it). What we're trying to say is that it's also sometimes very important to focus purely on the goal and see how it can be done with the least amount of time and effort, then pick an approach which is somewhere in between "most flexible" and "quickest" if you want to successfully create software that people actually use. I think your first approach is too oriented towards flexibility and not enough towards the pragmatic and more quickly achievable.