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. http://www.nomachine.org/ 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 -- http://mm.glug-bom.org/mailman/listinfo/linuxers
