Forum OpenACS Q&A: Response to cyber cafe management module

Collapse
2: Response to cyber cafe management module (response to 1)
Posted by Li-fan Chen on 01/22/01 01:04 AM

Cons: The internet kiosk and cyber cafe industry hasn't faced a lot of success and growth in the last decade according to industry reports.

Wants: The hardware and shop arrangements begs to be distributed in a reliable system similar to the StarBucks franchaise: 1. Same software; 2. Same people who wash the shoppie's clothings; 3. Everything you would want automated and replicated in a franchaise. Etc Etc.

Full-blown: I guess the first thing to making a ACS based Cybercafe module work and work well is to have some ACS-friendly development company champion that module and build an entire Cybercafe business around it. You would want this company to have a factory building durable and cheap cabinets for Internet consoles and the payment stations. You would want this company to have a system of assigning employee work schedules, coffee and mug orders. Etc etc. Why is this necessary? Because ACS is much too large a system to install just for the Cybercafe module. The ACS programming and administration overhead alone would kill you if you just want to send out a few stand-alone stations through out a shopping mall. Without ACS, you still have to do the following:

  • Billing Station programming.. it's basically a POS and Firewall together.
    • The Firewall figures out which Internet console is spending time.. and bills the account being spent by the person sitting at the Internet console. The firewall has a way of billing you for certain sections of the web (Everywhere); blocking certain sections of the web (The pr0n); and giving you free access to certain sections of the web (The How to Use the Internet Console pages for example). It may have to cooperate with some helper programs running on not only Linux but Windows and Macs to help your system learn how NOT to charge people $2 just because they are a slow typer in hotmail.com. These helper programs also talks to the POS system to help the POS system figure out if you are authorized (user/password) to spend time stored in a certain account.
    • The firewall/router also needs a group of nice admin-only CGIs to access setup procedures.
    • The billing station could do IP-based billing.. so it's probably just a bunch of Perl scripts accessing a few more helper perl scripts.. which makes the final IP call to a centralized Oracle database... which could bundle all the payment systems together into one central point.. so you don't need a VISA Vendor account for EACH AND EVERY remote cluster of your kiosks.
    • The billing station would have C or Java programs with JNI wrappers and drivers to talk Parallel and Serial to Coin and Bill validation devices. That way people could take money. These programs run as their own daemon.. and uses IPC (named pipes) to talk to the loosely-coupled remote database (caching some billing information mirrored from the central Oracle database) stored in the Router to credit people's accounts. The payment station also needs a ridiculously easy to use payment GUI.
    • The billing system also needs to talk to the central database so that your clerks knows when to go in and empty out the coins and bills overflowing in the payment station.

This is all a lot of work and a lot of time. Your credit-validation machines will likely come from Las Vegas. If you build the payment stations yourself you need spares. The credit card validation bureau is a lot of pain for just a few kiosks and a few bucks. So if you do this -- makes sure your business scales -- ensure that you'll be selling millions of dollars of these installations to interested Kiosk-owners. Or it won't be worth it.