--- Christopher Bunting <[EMAIL PROTECTED]> wrote:
> >>You are missing the trees for the forest.
>
> Well, in regards to the type of applications that you mention, I'd
> like to see a list of those coded in C.. PHP is moreless the standard
> language for use on the web as you mention. hotscripts.com shows that
> php scripts are written now at twice that of Perl, JSP, ASP, ASP.NET
> and so on.. Sure, there are tons of apps written like shopping carts
> using backends, But they don't allow access via a c program and sql..
> Again, talking about SQL brings up all the topics about C and it short
> comings, not what is being done in regards to web scripting.
I fail to see how a DB application would be any LESS efficient when written in
a lower level (high performance) language like C. The fact that people don't
use C for their web applications is most likely due to the number of language
extensions PHP provides for the rendering of HTML, and handling of form
submissions. C does not have any significant shortcomings when you're talking
about DB connectivity and querying, as compared to any other language. They all
use the standard API's etc, and any of them will work just fine.
> >>I specifically mentioned caching in my post, and it's incredibly important.
>
> I had no clue that C supported the use of caching and I can't find any
> reference of C being able to facilitate this. Not even a mention in
> the mysql c api docs. And I also don't mean the mysql query cache
> feature as benchmark tests show, thats a powerful system that is done
> on. Not anything remotely close to what would host a mud.
I think you (yet again) missed his point. He's talking about the memory caching
that ROM & other DiKU dirivitives (programs written entirely in C) already do.
If you looked at the source for rom you'd see that at startup the MUD will read
in all the data from area files. Then it stores that data in ram (linked via
various hash tables, etc) to make it quick to respond. If someone types "look"
in stock rom it doesn't go to the flat file to get the room description. It
pulls it from the the array (stored in RAM) and sends it to the client.
There is NO reason that after some changes to the area loading functions of
stock ROM the MUD couldn't be pulling all the data, via queries to the DB, and
store it in that same array (in RAM). So when clients connect and type "look"
the code would be identical to ROM. It's just that the source of the data that
is built at startup would be the database, not flat files.
I fail to understand why you choose to blindly ignore the statements of those
of us WHO HAVE DONE THIS, and continue to claim it's impossible. However, if
you continue to do so, I have no real interest in continuing this conversation.
~Kender
-----BEGIN GEEK CODE BLOCK-----
Version 3.12
GCS/IT/L/S/O d-(+) s++: a-(?) C++++$ UBLS++++$
P+++(--)$ L++++$ E--- W+$ N !o K? w(---) !O
M- !V PS+ PE(-) Y+ PGP->+ t+ 5 X++ R(+) tv+@
b+(++) !DI+++ D G(-) e>+++ h---() r+++ y+++(++)
------END GEEK CODE BLOCK------
__________________________________
Do you Yahoo!?
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/
