On 17/10/06 23:23 +0530, Saswata Banerjee & Associates wrote: <snip>
OK, either I dont understand what is going on or people on the group are being particularly obtuse.
The first.
Even with the database access and client server architecture, the software can only be used within the office.
Why?
It can not be used from outside the office. Today many of the clients you want will have multiple offices, and owners want to be able to access the data when they are outside the office.
And nothing stops them from doing it, except lack of connectivity.
Coming up with solutions like using ssh tunneling goes against your own aim of making and keeping the software simple enough to use without having to call an expert IT support personnel everytime you want to switch the computer on.
You are assuming that the tunnel will be exposed to the end user.
Also VNC is pretty much point and click, and tunneling it using Putty on Windows (if you WANT to use Windows) is trivial.
Most companies will in any case be cagy about allowing external access to an internal LAN network. It is different to set up the firewall to allow apache to serve pages to users from outside the office.
HTTP *is* a client server mechanism. Technically, the tunnel is a more secure way of doing things.
And how will you allow the owner to access the data from outside the office (say from his home).
Not a problem with a client server arch.
Client Server arch is a negative point in this scenario. Client Server tech was designed to work inside the same office.
Please do not confuse between peer to peer and client-server. A client-server architecture implies that there will be central system (the server) to which all other systems connect (the clients), make requests and get back responses. A peer to peer architecture implies that either side can initiate a connection, and the other can respond.
A common example of a peer to peer system is the IP. All hosts are equal in theory (NATted hosts are not peers). Examples of a client server system are the various protocols which sit on top of IP, such as HTTP, SMTP, POP3, IMAP, FTP, ...
This has nothing to do with a LAN, a MAN or a WAN (which are physical architectures).
Will you allow an user from outside the office to log into X ?
A policy issue not a technical one.
This policy issue is very important. Not taking this into account is going to be a very stupid move.
Important? Yes. Should application writers take it into consideration? Not necessarily.
Scenario 1) The user will connect to the database from a remote office. The user has a local X server, and a copy of the application configured to connect to the main office. This will work fine. Scenario 2) The user will connect to the main office via a VPN (per user, or site to site), and then login via a X server provided at the main office for that purpose.
How much bandwidth do you need from working from outside the office
Depends on what u are doing and on how u have written your app, but would work on a reliable 64kb connection.
We are working with multi-branch set up in our clients offices. We have 1 mbps triband lines connecting each of the branches. Even with that, and with ssh tunneling set up, we find the set up a problem. I suspect the 64kb line is going to be a source of frustration in client server arch environment.
What are you doing on those lines? Is it the bandwidth which is an issue, or the latency (different issues)?
Devdas Bhagat