>
> 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.
I've not noticed TCL apps crashing alla time; true they aren't speedy (I use
exmh, so I'm familiar with both aspects).
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.
You need something that's easy to use; this is why I suggest you use a GUI
toolkit of some kind.
>
> >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++.
Ask RHI why it switched from an installer written in C to the new gui one
written in python.
> 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?
if there are any lurkers in any doubt, unpack some kernel source then try
these alternatives for configuration:
make config
make menuconfig
make xconfig
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.
> >> It would be best if such app talked either HTTP to the bugzilla
> >> pages, or in case the chance that the pages change in any
> >> significant way, a bugzilla server app perhaps? Any other
> >
> >If it uses http, it can't be sure of getting my email address right.
>
> If I write it, it wont be doing anything behind your back. It
> will need to be configured properly first, and it will ask you
> for your email address, perhaps attempting to guess first by
> looking at your local hostname, username, perhaps inside .pinerc,
> or whatnot... It would allow you to decide though.
>
> >Unless there'sa good reason to use http, don't. You could
> >always prepare a datastream for a post, then mail it as an
> >attachment. Something at the bugzilla end reads the mail and
> >files the attachment.
>
> 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.
>
>
> >If RHI is using an sql database, it shouldn't be hard to prepare and submit
> an
> >sql statement.
>
> 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.
>
> >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.
>
>
> >> thoughts? Lets brainstorm this one out fully. Get some decent
> >> feedback going here, and plan out an application. I'm sure it
> >> will be received well. Perhaps it should be moved to
> >> redhat-devel though..
> >
> >We're here now;-)
>
> This is pinstripe-list... I suppose the topic is relevant
> partially, but discussing development of a new program seems to
> fit redhat-devel better, so I've Cc'd that list, and will remove
> pinstripe from replies.
>
>
> >> >Potentially, the information would be better than bugzilla gets now.
> >>
> >> I agree fully with that too. I've planned on writing some kind
> >> of bug report app for quite some time. I do something in KDE, it
> >
> >KDE's fine.
>
> No I meant "when I use KDE", not I'll write a front-end for
> KDE. Uggh... C++ programming.. no thanks.. ;o)
>
>
> >Or text-mode with GNOME & KDE wrappers. Someone can do other interfaces if
> >they like.
>
> Yes, that is my preference. If I start it up, it will be cleanly
> coded C. Either with an ncurses or slang text interface, or a
> GTK interface to start with. Of course, it would be open from
> the start, so others could start other interfaces as well at the
> same time...
>
>
> >> 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.
>
> 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?
_______________________________________________
Redhat-devel-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-devel-list
