On 2015-6-19 09:56 , Kyle Sammons wrote: > Hey all, > > It's reaching the point in my project where I have everything running, > save the core functionality, which hasn't been updated/modernized yet. > Currently Pallet uses Tcl bindings for Objective-C to issue commands and > communicate with Macports, rather than simply piping input/output > to/from the command line. But, because Pallet is rather old, it still > uses the system version of Tcl, rather than the Macports specific > version of Tcl, meaning that currently it can't actually communicate > with Macports.
That really shouldn't be hard to fix. > So, I'm left at the decision to either try to link the two together and > continue development of Pallet the way it's been going, or, to scratch > it and convert it to just simply issuing commands and parsing output. So > I was hoping to get the opinions from the community, seeing as this is a > community application. :) > > The pro's for converting to a CLI/GUI application that I can think of; > > Pros: > -More future proof. Literally anything can change on the backend as long > as the commands remain the same. The CLI output has probably changed more than the API in the past. > -Smaller code base. The current code base is fairly large, and > converting it to a CLI/GUI application would significantly shorten it. This probably points to duplication of functionality between port.tcl and Pallet. That would be better solved by sharing of code, perhaps in a new front-end support library module. > -Future commands would be easier to implement. Not really, parsing some arbitrary text is not easier than adding another procedure to the bindings. Other cons: No progress callbacks No interactive prompt callbacks No separation of error/warning/info/msg output streams No ability to implement features that the CLI doesn't have Worse performance - Josh _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
