[IRCServices] cheers. ideas.

[Chris Knipe]

*shrugs*

----- Original Message -----
From: Andrew Kempe <andrewk at icon.co.za>
To: <ircservices at Snow.shadowfire.org>
Sent: Wednesday, October 11, 2000 5:44 PM
Subject: Re: [IRCServices] cheers. ideas.


> Services is a READ ONCE, WRITE MANY application. If you make changes to
the
> data in the underlying datastore, be it a database, binary file or text
> file, the changes would be lost at the next database save.

*shrugs*.  Andrew, it will be lost because of the way data is CURRENTLY
saved in the database.  Do you mean to tell me now that if I have a SQL
database, access the database from two applications, and update the
information from one.  Do you want to tell me the information change is not
going to reflect in the second application?  Maybe not if you dont ask for
it again, but SURE the information IS going to be there at the next SELECT
from the database.  Which is more than adequate in the way Services needs to
retrieve its information from the databases.

> Services would require a lot of work to make it support proper querying of
a
> database. The performance hit services would take would outweigh the
benefit
> imho. If one were to do it properly, with multiple threads loading only
the
> information needed to service the users and channels currently online,
> things would definately be better. However, let's be honest, this requires
a
> lot of developement, skills and time.

Once again.  How can you talk about the performance WITHOUT bothering to
test this?  Don't rub of a suggestion / idea just because you are not sure.
I made my first post, I've shown you my results.  I ask again, do you have
similar results for the databases currently in use?  No, I didn't think so.

> What we should focus on is writing an interface for Services that allows
> external apps to communicate with it.

What we should be focusing on, is to analyse services, and find out EXACTLY
WHAT and WHERE the bottlenecks in services are.  Sure, the databases might
be one of them, but wouldn't it be ALLOT easier if we know WHERE in the
databases the problem lies?  For one, what would happen if you created an
index on the databases for one thing....

> Back to your point about Brasnet, 98MB is a lot. However, it's not totally
> unreasonable. The thing I'd guess that is really taking a hit is the CPU.
> The algorithms were never meant to handle so much data. I am definately
> looking to improve the key ones.

>From a SQL based view, its bizzare, sorry.  Once again aswell, it wont be a
bottle neck on the CPU either.  But hey, what do I know...

---
Regards,
Chris Knipe
Cell: (083) 430-8151




---------------------------------------------------------------
To unsubscribe, send email to majordomo at ender.shadowfire.org
with "unsubscribe ircservices" in the body, without the quotes.