Re: what is going on with gtk.php.net?

Yea, how you skin a cat depends on what your going to use it for, cooking or...... But yea, a decent database should be able to handle the querys anyway, I have annoying habit of thinking to far "beyond" the current need sometimes. My original thought of using a tcp server came more from security for me and grew into ideas for perfomance. Since a gtk application lives on the desktop if you use a direct mysql connection that application has to have the permission to make the changes required. How do you securely lock that down per employee? While you can create per table and even field permissions in mysql you can't stop someone from directly deleting records for another employee if all the records are in the same table. By using a tcp server and some authentication on connection you can identify who is trying to talk to the system, Instead of letting the clients submit querys they would submit datasets. By parsing and building querys on the fly you can implement a per person level of security. Even if someone did manage to connect to the server outside of your client they could affect nothing more then they where allowed. Tony Leake wrote:

This time I understand more what you are saying. I agree with you that 1000 connections open is an overhead ( i don't actually know how much). In my scenario, if the user doesn't use the connection for a while it will time out. Next time they try to use it, it's gone stale and a new connection is established. That way only the users currently using the app will have a connection open. Your idea to cache the original 1000 dataset in a tcp server is a good one if performace were to become a problem. I still think that if I want to look up bob smith a query to 'select firstname, surname from wherever where surname like s%' would do the job. Then another query to bring back the details. If there are 1000 people in the company each looking up 10 names a day thats 20,000 queries a day. I would not worry about that on any reasonably spec'd db server. Anyway I can see the merits in your solution and I'm sure we could debate the pro's and cons for ever. More than one way to skin a cat etc tony On Thu, 2004-07-22 at 19:50, Richard Thomas wrote:

What happens if you have 1000 users all connected to the database at the exact same time, I wasn't talking the overhead really of the database in general but instead the connections to the database itself. In my address book example, Say you have an address book with every employee at the company, Typical format for an address book is to list names and allow you to scroll through those names, then click for more detailed, Its that original list of names that I was referring to in my example. Do you do 1000 querys to pull the same exact list or can you cache that list so the result is only a single query. The database handles all the updates so theres no problem there, If a change does come in you would have to have your tcp server clear the cache, the next request for the address book would query the db, and recreate the cache. As to memory usage, If you think in terms of your computer there are a number of diffrent types of caching going on in your computer at any one time, The idea of caching is not to store everything but to store frequently accessed data. Caching the list of people in the address book would make sense since any use of the address book would require this basic list, Caching every person in the address book however does not make sense. Tony Leake wrote:

On Thu, 2004-07-22 at 17:43, Richard Thomas wrote:

Such a "hack" doesn't seem like it would scale very well at all. It seems to me you would be better off with a diffrent form of communication between the applications, like possibly a tcp connection.

I can't agree that this is a hack and it scales very well. I use this methds in an application that dispatches goods from a warehouse. It is used by 30 - 40 simultainous users spread over 4 georaphic locations. It handles 30,000 transactions a day and since it went live has handeled close to 3 million transactions. Our database servers average 15,000 queries a second and do not even flinch so a couple of extra queries to make sure that the databsae handle is still alive is a tiny overhead.

A good example.. Large company address book, employees work 9-5, so a majority of your "initial" activity would occur between 8:55-9:00. 1000 employees connecting to the db and performing a query to load there address books for the data, then every time the address book changes each one has to reperform the query.

It sounds to me like your saying you load the whole address book into memory? In real life you perform one query to connect to the database when you start the database and another when you want to look up an address, then another when you want another address, not a big issue for any database.

Instead using some tcp setup it would happen more streamlined. 1. People connect, First person that makes request causes query, Final dataset built, cached and then sent.

I also use a tcp server in the same application,but there are times you need real-time which is far more suitable for a database.

2. Everyone else pulls a simple dataset out of the tcp server memory, low overhead.

Then when someone updates an address, everyones local copy has to be updated. What happens if 2 people try to update the same record at the same time. Lots of code to handle that, or your database will do it all for you.

3. Ability to send "broadcasts" over the tcp connection letting people know there are updates to the address book. Instead of everyone pooling the server now you have told everyone there is a update, Next time they open there address book it will pull it.

so if you have 50,000 records in the datasset thats quite a lot of ram used just to hold the data that you may never use. Tony

tony@php.net wrote:

On Thu, 2004-07-22 at 09:11, Anders K. Madsen wrote:

On Thu, 22 Jul 2004 12:57:46 +0700 (SE Asia Standard Time) xaviero1412@yahoo.com.au (Xaviero) wrote:

so, tony, could u write some article bout php-gtk that explain how to build an application such like address book that connect to mysql server ?

I'm working on one at the moment :)

Well, PHP-GTK is just an extension of PHP, so any PHP/MySQL tutorial would do in your case.

Almost, however you need to be aware that a gtk app is likely to be open on someones desktop all day, and may only be used for a few minutes at a time. When you come back to it your db handle has gone stale. I always extend my basic db class with a gtk specific one that checks the connection is alive before I use it. tony

-- Richard Thomas Cyberlot Technologies Group Inc. 507.398.4124 - Voice

-- Richard Thomas Cyberlot Technologies Group Inc. 507.398.4124 - Voice