Re: [Pan-users] Posting Binaries

[Duncan]

On Friday 15 November 2002 06:50, Sean Tomlinson wrote:
> At 05:58 AM 11/15/2002 -0700, you wrote:
> >OR, better do NOT require them in the depends, but provide a nice GUI
> >configuration dialog, browse buttons and all, where one could point PAN in
> >the right direction, to use them, if they are installed.  Ideally, there
> >would be default paths either hard coded or installed by default in the
> > pan config, and showing up in that nice dialog, to give the user hints as
> > to what TYPE of path is normally taken, but stability and not disturbing
> > a currently working setup should be higher priorities.
>
>          You mean a dynamic download and installation tool.  You know, you
> download a little program at first, tell it what you want and it happily
> downloads the apropos pieces from the Pan site or a mirror, and
> installs/configures the program...  Would make version control rather
> easy...

No, I didn't mean that.  Rereading it, I did leave out part of what I was 
thinking, however, so that could easily have been the impression I left.  
(BTW, MSIE's Active Setup, for instance, isn't bad, necessarily, but I don't 
think it's what PAN needs...)

What I left out was that PAN functionality should "gracefully degrade" when 
they are not installed, or not in the location or accessable in the location 
where PAN looks by default and no other has been set by that nice GUI dialog 
I mentioned.  Thus, if it were to be able to take advantage of newspost, for 
instance, to allow auto-posting of large groups of files, were it installed 
and PAN could find it, newspost shouldn't then become a dependency on the 
RPM, for instance.  PAN should just not have that functionality, if it can't 
access the backend tool that provides it, possibly, with a note upon 
invocation that the functionality can be added by installing X additional 
tools, and giving a URL, either on rebelbase or at the backend program's 
site, for download or for more info.

Thus, for instance, it would be like KPackage or Ark, from the KDE 
environment.  Quoting the Ark Handbook... "To handle other file formats, you 
need the appropriate command line programs, such as zip, unzip, ar and lha."  
The appropriate KDE RPM doesn't require them for installation, neither does 
compiling them from source, but to use that functionality, Ark needs to be 
able to execute those backend programs.

-- 
Duncan
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety." --
Benjamin Franklin