Sure, but this places out of the scope of avrdude, or any other part of
the toolchain.
Why is it out of scope? Do you want a tool that solves peoples' real
problems, or do you want eye candy?
I think the question is: why do we need the GUI? If you need it for
factory use, it has to be highly customizable, as different companies
have different needs.
If you want to make something easily customizable, it may be that the
approach of a monolithic thing written with C is not the best possible
approach. I would use wxPython (and have in similar cases), as it seems
to give a good how-good-it-looks-and-how-well-it-works to
how-much-head-scratching ratio. I have not tried that many tools, so
there may be something even better available.
If we, instead, say that the GUI is only for developer use, then a clean
monolithic GUI is absolutely fine. It will make avrdude a more
interesting choice for those using AVRstudio at the moment, and it will
bring the GUI to non-MS operating systems. But if there is no serial
number mechanism, no place for instructions, and customizing is not
easy, then it is not for factory use, IMHO.
---
Something I mentioned a while back that seems to have been lost in the
noise is the idea of implementing the gui front-end as a web browser
interface.
First time I saw this suggestion I thought it is not a very practical
one. I have written AJAX interfaces for some measurement instruments
with internal web servers, so I have scratched the surface.
Also, our current programming systems use PHP-based interfaces through
the web browser, and there are several problems. The most difficult one
is that there is no "push", only "pull". If you want to have a status
indicator, you'll need to poll something somehow. Java is difficult, so
everything has to be done either server-side or with AJAX.
But after thinking this for the second time, I have to admit there is
something. All communication between the interface (i.e., the JavaScript
stuff running in the client) and avrdude (the web host) could be done
with HTTP POST and XML stuff. If the status is polled, e.g., once a
second, it will be enough.
However, there are a few challenges here:
1. We need to have a separate process (the cgi-bin) which is able to
query the status of avrdude at any time. Communication between these
processes requires some thinking. (I would use UDP sockets, but, again,
there may be much better ways.)
2. Writing a web server is beyond the scope of avrdude, so then we'll
need to start thinking Apache or something else.
3. How would it be possible to load a file from the client to the host?
There is a mechanism to send files over HTTP, but that requires some
work at the server end. Otherwise the files need to be at the server,
which may or may not be a clever idea. (For example, OpenOCD has some
problems with this.)
There are several possible architectures, but what I would do is like this:
avrdude server (at UDP port xxxxx)
cgi-bin (talking to the avrdude server)
JavaScript (at the client, communicates with the cgi-bin's)
This would enable any split between the parts, they could all be in
different machines. It would also enable someone using the UDP interface
instead of the CLI, and thus the API would be moved to a well-defined
abstraction level (= no recompiling required). The problem here is that
it is not a very small programming effort. It would be nice, but...
- Ville
_______________________________________________
avrdude-dev mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/avrdude-dev
