client application talking to apache/php

Anon

i am making a simple client in vb, but the language really doesn't matter.

i connect to my web server, get the results and then display the raw data in a text box on the application. my scripts used for the client application return only text, so HTML formating isn't neccessary.

HTTP is stateless, but i want the client app to maintain state securely.

here is a simple solution:
have a login box on the application that then gets the users ID via HTTP GET if the passwords match. then on every subsequent request from the server, put the ID and other info in a GET string and request it from the server.

that solution is INSANELY insecure, but it encompasses what i want to do.

so you understand what i want to do, here is an example. lets say i have a checking account and a savings account on this server (don't freak out, i'm not doing this for a bank... your money is safe) 🙂 anyways, the users would log in, and the server might respond with the persons id and current balances. so the client app shows the balances... now the user wants to transfer 500 from savings to checking. i can check on client side now whether the funds are sufficient before sending to the server. ok, so we checked and they have enough money... so we somehow send the person id, and the desired transaction. the server double checks the balances to make sure everything is ok, and then updates its records, and responds with the new balances.

WHY AM I USING A WEB SERVER TO DO THIS AND NOT A CUSTOM SERVER? i want users to be able to do the same transaction securely on a web site (which already works), but with a client app, i could save a TON of bandwidth (because the client app renders all the pages and doesn't need all the HTML formatting) and i could also add a lot of cool features not available to HTML, Javascript or flash. plus it would be faster for the end user.

if no one has done anything like this yet, i think it would be a VERY good application.

help me out!

reagent

I don't understand why you would try to move away from an internet architecture (for lack of a better word). You're bringing yourself back to having to worry about making sure your users have the most up-to-date version of your software, something that you don't have to worry about when you are using a web application (in theory of course).

As far as saving bandwidth, I'm not sure I see how this will accomplish this. If you are retrieving the same data, it will have the same impact on bandwidth, regardless if you render html on the client.

Anon

i am not moving away from internet architecture, i am offering a more feature filled alternative.

as for saving bandwidth, an example is in order...

my average account HTML page is around 30KB... if i just send them 100B of data, and they can render the same page locally, that is 300 times less bandwidth used.

reagent

so you would be caching the account page after you get it, or will you be serving up different content depending on how your custom client identifies itself? I'm not really seeing how you will send one client 30k and the other 100 bytes.

Also, have you given thought to keeping the users' software up to date?

Anon

back to the example i think... the pages are fairly complicated and include a ton of javascript and stylesheets. if i design a layout in a client application, i can build all the javascript functionality and css into it automatically, so that stuff is scratch. the layout is also scratched because the client app will take care of it.

the application will be assumed to be in sync with the server so any hacking will be pointless because the server will still make and verify all transaction.

so lets say i have 30k of account data (not layout, pure data)... so i send in some set protocol a command to "do this transaction with these parameters", the servers response would be just like a function call if you think about it... so the client app just alters its data and mimics it to execute the transaction on its own data.

so i send about 50bytes of commands, receive maybe another 50bytes of HTTP headers and a server response and i didn't have to transfer much at all.

because of the simplicity of the system and modularity of the protocol, the software will not need updating and would be done voluntarily. if i wanted to get fancy i could always auto update the software on requests, but it seriously is not neccessary.