On Thu, 17 Aug 2000, John Summerfield wrote:
>> If I wrote such a beast, it would be straight C, with an API to
>> plugin various frontends to such as discussed above. That way it
>> works everywhere. You install the frontend for your prefered
>> environment. No reliance on perl/tcl/tk/python or whatever...
>
>
>Speed of the app is completely unimportant.
Agreed. But C argument is not for speed. C argument is so that
every system out there can run the bug report tool, including
minimal systems with no perl/tcl/tk/python/pike/java/whatever.
The raw C program will work from the text commandline either as a
simple sequential Q&A program, or as a fullscreen
ncurses/slang/newt sort of thing. If done right, it could have
hooks for tcl/tk frontend, as well as gtk/kde, you name it. Look
at Linuxconf as the example I am thinking of. It is written in C,
and has lots of interface frontends, thus maximizing the
usefulness in different environments.
Bugs occur in all linux systems, not just ones with X
installed. ;o)
>I've not noticed TCL apps crashing alla time; true they aren't speedy (I use
>exmh, so I'm familiar with both aspects).
I use Xcdroast, and it is quite a slow job. It leaves itself
crashed in the background a lot. All TCL/TK apps i've ever used
were crappy with stability and speed. Ever _look_ at TCL/TK
code? No thanks.. that is one thing i'll never learn. Too many
better more well structured languages out there that are more
modern and less messy.
>Anyone who uses control-panel or "make xconfig" to configure a
>kernel has TCL installed. There's lots of other stuff uses it
>too; it's almost mandatory.
Yeah, two more examples why I hate TCL.. Thanks. ;o) Actually,
first time I ran "make xconfig" it had too many screwups, and
when I asked why, I found out because it was TCL/TK. Not as
maintained as menuconfig too.
The control-panel app crashed on me so much that I uninstalled it
years ago. Same thing with glint, the ancient RPM frontend. It
would get in some recursive loop that brought my loadavg up to
10. It got nuked too. Only reason I have it installed is for
xcdroast, and xcdroast's days are numbered (the gtk version is
going to replace it). ;o)
I do have a few decent TCL apps, such as the Cygnus tools, but
they are the exception to the rule. They are very cool.
>You need something that's easy to use; this is why I suggest you use a GUI
>toolkit of some kind.
Oh, I will. ;o) You must have misunderstood me.. The core is
C, the frontends can be anything. My interest is GTK and slang
primarily as well as a Q&A console thing.
I will likely start by prototyping with perl though. Perl is
good for prototyping.
>> >Just so long as the software to run it's on the CD.
>>
>> Yes, the frontends could be written in anything, but there should
>> be a C ncurses frontend minimum as most people can run that,
>
>I personally have a pretty dim view of C as a programming language suitable
>for anything much more than kernels and such. C++ is better. I really think
>one of the interpreted languages will get an easier-to-use reporter ready
>sooner (much sooner) and with fewer bugs than something written in C or C++.
Hence perl for prototyping. Proof of concept, then port to C. I
won't use C++. I don't know C++, and am not really interested in
it much at all. C is standard, C++ compilers in Linux are not
very compatible at all. To write in C++ basically means to
statically link.
>Ask RHI why it switched from an installer written in C to the new gui one
>written in python.
I already know. The logic for that is good for what they needed
to do. Python would be probably an ideal solution as well for
this, except I don't know python, and I am not ready to start
learning YAPL (Yet Another Programming Language). I'm doing
Perl, possibly Pike, XML, and enough other things right now, I
don't need my eyes crossing any more than they allready are. ;o)
C ensures it will work wherever C libararies are installed, which
is pretty much anywhere.
>> either at the console, in Xterm, or otherwise. If need be, a
>> oldfashioned question-response script kindof thing could be the
>> lowest common denominator. Something like the options available
>> in the kernel config process...
>
>They are truly horrible. Do you still use "make config" to build a kernel?
No, but it is there so that people can use it even on systems
which are very minimal without X, and without ncurses, etc..
Having something be compatible with raw text terminals means bug
reporting can be easily done there too. Why limit support to
just people running X with TCL/TK installed? Why not have the
low level stuff work anywhere and layer various interfaces on
top. Much better design IMHO.
>if there are any lurkers in any doubt, unpack some kernel source then try
>these alternatives for configuration:
>make config
>make menuconfig
>make xconfig
No question. menuconfig is the easiest and most used, xconfig
just as easy but less used, and often buggy.
>The IBM DB2 install script is pretty gruesome too. But it IS menu-based. And
>it shows just what can be achieved in a shell script.
Oh, I am not disagreeing. I'm just wanting to provide options
for every case out there. No limitations. That will please
everyone.
>> Does bugzilla have an alternate interface than http? If I were
>> writing a client side frontend, I wouldn't be writing a bug
>> reporting backend to replace bugzilla. If bugzilla uses http
>> only, then http it is. I don't see any problem. I like the mail
>> idea too though.
>
>If bugzilla REQUIRES http, then a bit can be added to it to run wherever it's
>installed to accept a text file and use http to store it. it's a simple matter
>to feed email into a program, I do it all the time. That program could (be
>written in anything) and do some sanity checks and then do whatever BZ
>requires and reply to the author.
>
>It could also implement some enquiries; even if not at first, then allow for
>the possibility later.
>
>The code's pretty much the same (especially the http bit) but it runs at the
>server end, not the client end.
Well, if done modularly, here is how I forsee the whole app:
Very independant core functionality. Many different GUI/TUI
front ends can interface to it. The output would be modular
too. That way it could talk to bugzilla via HTTP, or some other
method. New code could be plopped in to have it talk to other
bug reporting systems in common use too, via HTTP, email, or
whatever.
It could potentially become the standard bug reporting client,
compatible with anything someone has the guts to add support for.
>> Keep in mind the security aspects of this too. Submitting email
>> to the thing needs to be secure. People could submit cron jobs
>> or /fat32/autoexec.bat as a bug report directly. How would the
>> server side handle it? How would authentication be done via
>> email? With HTTP you have to log in. With email you have a
>> sink. A sink open to spam and a horde of other things. It is
>> possible but would have to be done carefully...
>
>If you're not registered....
>Can be handled with
>a) Email addresses it knows.
>b) Special headers
>c) PGP signatures.
>d) You could use encryption. If it doesn't make sense, ditch it.
>
>Whatever you do, it should be very easily setup at the client end. Not
>everyone has implemented PGP, and they sure don't want to spend half an hour
>sorting that out just so they can submit a report.
All good ideas. I agree with all that, sounds good.
>> >Or maybe it should go dressed up as xml; that seems to be in
>> >fashion right now.
>>
>> Ugg. Perhaps... The phrase "XML" is sounding more and more like
>> the word "millenium" to me every day... getting sick of it. ;o)
>
>It's one way that's extensible; if someone wants to add more fields, it's
>easily done. And there are free xml parsers out there.
Right, that sounds good. I need to investigate XML more.
>> >> Who all is interested out there in taking on a project to provide
>> >> a front end to bugzilla? If there are enough people, perhaps
>> >> I'll start a new opensource project on source forge. I guarantee
>> >> it WONT be called "bug pal" or anything anal retentive like
>> >> that.. ;o)
>> >
>> >bugger.
>>
>> Heheh. That word has different meanings in North America, and
>> Britain. ;o)
>
>It's not the only one. Take the sentence, "A wombat eats roots and leaves."
>It's an accurate description of a wombat's diet, but it's open to another
>interpretation.
What? ;o) I don't know what a Wombat is. Is that something
down under?
>> If the text interface is "bugreporter", I'll assure that the GTK
>> version won't suffer from the common "gbugreporter" braindamaged
>> naming convention. ;o) I'm more inventive than that. Something
>> like "gtkbugreporter". Hahaha. Just kidding! ;o)
>>
>> "crashomatic"? ;o)
>
>W* has Dr Watson. Can we have Holmes?
Hehehehe. Another cool name. ;o) I'll keep it in mind too.
TTYL
--
Mike A. Harris Linux advocate
Computer Consultant GNU advocate
Capslock Consulting Open Source advocate
Try out Red Hat Linux today: http://www.redhat.com
ftp://ftp.redhat.com/pub/redhat/redhat-6.2/
_______________________________________________
Redhat-devel-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-devel-list
