Re: [avrdude-dev] Avrdude Gui problem (web interface?)

[Ville Voipio]

> > 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