On Tuesday 17 October 2006 23:23, Saswata Banerjee & Associates wrote: > jtd wrote: > > On Sunday 15 October 2006 23:38, Saswata Banerjee & Associates wrote: > >>>> Second, I think we should build web-based software. It is > >>>> easier to run > >>> > >>> I disagree. Web stuff is far harder to get right than a plain, > >> > >> X will work in the office. How will you connect multiple offices > >> to the same database ? > > > > That is one of the reasons for using databases - concurrent > > access. > > OK, either I dont understand what is going on or people on the > group are being particularly obtuse.
sorry for sounding obtuse. I presumed several little thingies as understood. > Even with the database access and client server architecture, the > software can only be used within the office. > 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. You can access a database (including flatfile "database") over a tcp link. The network is taken care of by the os. U woulsd require your app to be running on the machine u are using for access. > Coming up with solutions like using ssh tunneling SSH tunelling, vpn, encryption etc, are for ensuring security over public wires. You could do away with the security part and things would still work the same. Additionally with ssh u do not require the app on the remote machine. > 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. If u want security there will be some amount of setting up depending on the clients conectivity. Most customers would fall into a few broad categories anyway and once setup the same can be replicated quite easily. > > Most companies will in any case be cagy about allowing external > access to an internal LAN network. The requiremnt of external access is in direct conflict with this directive. > It is different to set up the > firewall to allow apache to serve pages to users from outside the > office. Which is same as external access minus the security. > > >> 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. It was designed specifically to allow multiple users accross diverse geo locations to access databases, which ofcourse worked even better on a lan - 10 mbps shared over 150 to 250 machines - which translates to well below 32kbps per machine. > >> 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. Saswata u are mixing up things. Once u decide a policy, the networking portion will be battened down accordingly. It has almost nothing to do with the capability of the database to accept a connection over the network. To us a network is two points capable of pinging each other, the physical location is of no consequence given the right policy. . > >> 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 have setups working on a mix of dialup 9600 bps (one or two machines), ISDN and triband too. They work without a "hitch". Occasionally the triband connection will fail, requiring the modem to be rebooted, for which u wire up a gizmo to the GNU/linux PIII firewall which is pinging several external ips and knows when to reboot the modem. About once in several months MTNL will conk out and require manual intervention. Ofcourse there are critical locations and such things could be a disaster. In which case u use LL and ISDN backup. The problems u are facing could be one of the above, in addition to occasional high latency. Also your app may be using heavy widgets as pointed out by DB or might be downloading the entire screen from the server another big nono. > I suspect the 64kb line is going to be a source of > frustration in client server arch environment. depends on many things. But with a properly written app, it works well. As u can see access from multiple locations is a given, subject to policy, and will not affect us as we should be writing the app to work over a thin network. -- Rgds JTD -- http://mm.glug-bom.org/mailman/listinfo/linuxers
