Architectural proposal

[Michelangelo De Simone]

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?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2409 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080323/086ab791/attachment.bin