Architectural proposal

[Jordan K. Hubbard]

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 see Rainer has already said many of the same things, so I'm clearly  
not alone. :-)

> Anyway thank you and don't be concerned, I really appreciate direct  
> approaches.:)

I'm glad to hear that since those are the kind I like best. :-)

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.

- Jordan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20080323/ce864e31/attachment.html