Go for the browser interface. The GUI is usually referred to as the "frontend" in a user app, "backend" meaning the supporting database/filesystem and maybe the cgi itself.

To connect to a Tk app, the user would need to establish a remote X or vpn connection. That would be really unusual, generally requiring an account on the server.

Hi,

I would use a web interface, because you can take a lot of code and experience from doing the shopping cart -> reuse.

And of course you can limit access to this section of the webserver by host, user, or whatever you want. The user don't need to acommodate to a GUI, he uses the same software (web browser) as he/she usual use. You save time, because, you don't have to create and think about how to style and define the user interaction etc... of course you also need to do this in the CGI version, but you don't need to change concepts, you still work on the same as you have, but you extend it.

And, ok, that's not a potential factor, but it's prettier... because you handle there with html,css, etc...

Another way you could think about, for testing and experimentation is to doing it with XUL

Regards,

Of course, I'm biased toward Tk, but there are advantages to using it, especially if it will only be run on 1 machine( i.e. no access needed thru the internet).

The main advantage is that you don't need to hassle with the programming ideosyncracies of the "stateless http protocol", like sending hidden fields, and storing sessions.

Tk will also give you a richer set of widgets to do your backend work. The html widgets are very limited, whereas as Tk will let you do just about anything you can dream up.

The Tk version "may" be more secure, since you are avoiding the unneccesary "apache middleman". If you have to setup a local apache server, for your workers, that can lead to complications....like firewall access, security issues, etc. Additionally, with Tk, you will be able to access more of the local filesystem and commands, without having to resort to using "sudo tricks".

So I would say, the only reason to use a browser interface, is if you want to remotely administer the store. But there too, Tk can access remotely thru encrypted connections.

Just as an example of the value of using Tk, just think about the problem of printing up shipping labels. I think it would be alot easier from a Tk script, than it would be thru a browser.

Thanks for that!

I didn't mean to confuse the term backend, but since it's not a cgi app that is going to be web accessable I considered it a backend app.

That said, all this app is going to do is grab encrypted e-mails from the mail server, decode them locally, and print up receipts/mailing labels. And if I had users that were more computer savvy, I would be doing this in Tk in a heartbeat. But given that the person using has probably had about 5-10 hours total computer experience, I figured that the browser interface would be preferable.

Useless trivia: In the 2004 Las Vegas phone book there are approximately 28 pages of ads for massage, but almost 200 for lawyers.

Concerning web applications, I dislike the fact that you have to complete reload your page for the tiniest change. By chance I found CGI::Ajax at CPAN which makes it easier to use XMLHttp. disadvantage: it produces and uses a lot of JavaScript/DHTML.

"I dislike the fact that you have to complete reload your page for the tiniest change."

100% agree, and technologies like XML island (DHTML category) etc is aimed to address this issue. At this point, it seems like javaScript/DHTML is the most common way if you wish to address this.

Add a little bit for people who is not familiar with DHTML: it is not another standard similar to HTML or XHTML, but rather a very vague concept to group any technology that make web page "dynamic".

The downside of a browser interface is you'll have less control of the interface and will have to fit your app into the browser's constraints, particularly the stateless environment.

Although web will ease your deployment effort, the development effort is very high if the user interface is complex. For stand-alone application, the development effort might be a linear function of the interface complexity, for web, it is exponentiation.

Although stand-alone user interface might be easier, Tk is not neccessarily the best.

Also: plan for success. Looking ahead, imagine you need 2-10 instances of the backend application. Seems the browser version becomes even more desirable then.

If you rope in Catalyst with a side of Template and Class::DBI you can probably recycle any base modules you wrote for the customer side and might be able to get a skeleton/working application done in just a day or two.