Another Linux Compile problem

[msknight]

Dropcalc on the same server to have access to chat and system logs.

Yes, moaning is justified when a shift from SQL to XML is done and I still haven't heard why XML is preferable over SQL. So my work is defunkt for no good reason.

Dropcalc was silent because I'm ill. Osteoperosis, partial prolapse, heredetary liver malfunction producing too much cholesterol, memory impairment and more.

Tell me ... why is XML good over SQL.

[msknight]

By the way, it is not a one way job.

The dropcalc has the ability to allow the administrator to create new mobs based on existing ones. Features like this are impossible if the dropcalc can't write back to the XML.

[poltomb]

And STOP writing my nickname wrong!!

But it would be so much easier for me to remember jurkis! ...jurkis, jurchiks...I like jurkis better.

@msknight: I see...that could prove difficult. You could look into XQuery. I have no idea how it is with regard to performance, but it is a simple sql-like syntax.

[msknight]

The main problem with writing back to the xml data is file permissions.

The dropcalc usually runs under a user name for the web process ... and it would be dangerous to allow the web process to have write access to any files of this type.

It may be feasible (however easy/hard) to work around a lot of the issues of allowing the dropcalc to write back to the XML files, but it opens up a bit of a security hole.

The main reason for my anger is that if there is no good reason for making that transfer, then the dropcalc's work becomes difficult for no good reason ... and that is what is so hard to stomach. It is difficult to hear those complaining about my complaining, but not answering my main question.

I'll just sit back and wait to see the argument for taking the sql to xml.

[msknight]

A last thing, and also which has been hard to read and fuelled my feelings...

The way many of the devs write, who don't use the dropcalc ... is as if the dropcalc is simply an external thing that can be happy with off-line data.

In using the dropcalc, it is so much a part of administering the system that these changes will very badly cripple it. The dropcalc and the supporting maintenance/policing scripts were developed from peoples calls to administer the server without needing to either have SSH access to their box, or needing a PC with a game client loaded on it. That is what the dropcalc expanded to become.

To hear people writing about it as if it is some throw away piece of nothing ... well ... it hurts.

Now, I'll shut up.

[jurchiks]

Administration tools are not part of dropcalc, even if they are integrated, they still don't go by the same name.
Dropcalc is ONLY for showing mob drop, anything else is already administration and that's another thing.

Just for showing info (NOT editing it) parsing xml is enough and that's what a normal dropcalc should be all about.
Editing it through a web interface that connects and writes to DB is a security risk in itself, not much different than writing xml.

P.S. this topic has gone WAAAAY offtopic.

[poltomb]

Administration tools are not part of dropcalc, even if they are integrated, they still don't go by the same name.
Dropcalc is ONLY for showing mob drop, anything else is already administration and that's another thing.

Just for showing info (NOT editing it) parsing xml is enough and that's what a normal dropcalc should be all about.
Editing it through a web interface that connects and writes to DB is a security risk in itself, not much different than writing xml.

P.S. this topic has gone WAAAAY offtopic.

This dropcalc started out like that, but msknight is saying that it has evolved into a more feature rich server administration tool in addition to the standard dropcalc (btw, i hate that they are called dropcalcs, since they don't really calculate anything, they just show data...more of a drop viewer but that's off topic). Just because dropcacl is the name of the tool, doesn't mean that it all that it does.