RPM Community Forums

Mailing List Message of <popt-devel>

Re: Teaching POPT 2.0 about HTML/XML/YAML?

From: Danny Sung <danny@dannysung.com>
Date: Mon 07 Jun 2010 - 20:24:55 CEST
Message-ID: <4C0D3977.6000509@dannysung.com>
On 6/5/2010 10:55 AM, Jeff Johnson wrote:
> Note that a opaque (*help_transform) pluggable callback
> is what I propose ... no way do I want to see POPT start
> acquiring heavyweight linkages like -lxml2/-lexpat/-lsyck/-lwhatever.
>
> But almost certainly a reasonable API could be added so that
> --help transforms, with some reasonably simple (like the existing
> --help CLI display) transform vectors within -lpopt explicitly.


Actually I really like this idea.  This would effectively introduce what 
could be a plugin architecture for popt.  Ideally this should be  done 
in a way where someone could create say an XML output and release a 
separate library called popt_help_xml or something.

One of the concepts I've been playing around with is having the help 
system double as a mechanism for programs to figure out what options 
other programs have.

For example, it seems common place these days to write GUI shells on top 
of command-line utilities.  However, it's difficult to know what exact 
parameters are available for a specific build without a run-and-test 
operation.

So this mechanism would allow someone intrepid developer (or perhaps GUI 
framework people like gnome/kde) to establish a standard for doing this 
sort of thing.



The plugin/callback thing goes even further though.  Even your 
optionTable could support something like this.  So in the case of your 
auto-increment feature... this could actually be a "plugin" to popt, 
allowing someone else (either the app developer) or a plugin author to 
write.

If done well, it's possible you'll start getting developers join you by 
submitting plugins to the "default" installation.

Also, I don't know how others feel about this.  But if it makes things 
any easier (esp. if it makes it easier for the app developer), I'm 
actually sort of okay with an external utility generating the options 
table, and just allowing me to #include it in my source.

This has the potential of making the options table much cleaner/flexible 
as it wouldn't be limited to c-style syntax.
Received on Mon Jun 7 20:25:33 2010
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.