XML Parsing - mIRC Discussion Forums

is it possible to add xml parsing aliases
i know there is some dlls that do the job
but it would be amazing to add this feature
it is a better way to store mIRC settings too

What makes it a better way to store mIRC's settings?
It uses an INI file at present, something that is already parsed by mIRC.

I've never been a big fan of INI files, but you're statement that it would be better seems somewhat un-clear, could you please explain how it would be better? Human readability?

mirc stores settings in many ini files mirc.ini server.ini control.ini etc
this feature could help save a whole mirc season in one file
<options>
...
</options>
<servers>
<server>
<addr>irc.addr</addr>
<port>6667</port>
<accounts>
<account username="" password="" />
</accounts>
<favourites>
<channel>#name</channel>
</favourites>
</server>
</servers>
looks better ?
ini files lacks the ability to nest data storage in a tree
u can use many ini files one for many sections but,,
when u want to rename a server for example
without changing accounts and favourites
u will have to rename each ini file used

I see what you mean, but that hardly looks better than

[irc.somenet.net]
nickname=SoMeNamE
server=irc.somenet.net
port=6667

etc

Not quite what you're looking for, but sure this parser will come in bandy
Mpdreamz's XML parser using COM

People who think XML is a better configuration file format are sorely mistaken and are all eating it for their initial opinion. Even the creator of Ant (the infamous Java based build tool) admitted that XML was a bad decision. It's hard to read, error prone to write and overly complex to manipulate even for a machine. You can fill a book with the API (let alone the specification), and using it is not pretty, even in the highest level languages.

Ini files are simplistic and obvious, both to a user and to a machine. Configuration files don't need "nesting". Nesting doesn't make parsing or accessing data any easier, either.

Of course, none of this has anything to do on whether mIRC should have XML parsing capabilities.

Writing an mIRC based parser would be easy, but probably ridiculously slow. Of course DLLs do the job just fine here, though with so much web out there, mIRC could be more helpful to socket scripts that try to integrate with web services (or scrape pages), which seems to be a common scripting task these days.

That said, XML is still a huge api, making it quite high maintenance for something to be supported directly by mIRC. It would require plenty of identifiers and plenty of API wrapping to work properly, so only time will tell if Khaled wants to take this up. In the meantime, use a DLL and don't expect this to be added to mIRC any time soon.

Don't get me wrong, I dont "dislike" the idea of mIRC parsing XML, I just dont see how it's better for mIRC's internal configuration.

Also, to be effective in parsing XML, wouldnt we need arrays or similar?

You guys aren't defining "better". If you mean "better" as in "faster", then parsing INI files is probably better in that respect, because it doesn't do as much processing. If you're referring to "more flexible" that's a different thing, however. Ease of use is a different aspect too, but it sort of ties in with flexibility. The more flexible you get, the less easy that option may be. For example, regular expressions.

Originally Posted By: The_JD

Also, to be effective in parsing XML, wouldnt we need arrays or similar?

errm. We do have something similar. Why are arrays really necessary to parse XML, however? I thought XML was all about the representation of structured data as a universal markup language, not about collections. XML is serialized, there are no arrays. Just elements, nested inside elements. The whole idea of XML is that you're supposed to know the structure of the information.

I think his point is that without proper data structures, the api for xml parsing would be pretty ugly.

Here's an example API (best I could come up with):

Code:

/xmlopen document file.xml
var %node = $xmlnode(document, root) 
; The above could return the root node of the document
; but how would it return it? as what? text? a unique node name?
; And how would we get the first children of that node, for ex.?

var %childnode = $xmlnode(document, %node, 1)
; The above would only work if %node was some unique identifier 
; across all nodes in the document, "node001" or something. 

/xmlclose document

You could probably think up a better API, but you'd still have to figure out how to represent any data structure as a set of strings, since that's the only inherent data-structure mIRC has.

The other option is to do something like binary variables and have "xmlset NODENAME document PARENTNODE 1" to set $xmlvar(NODENAME) to a node, but that's equally odd.

Originally Posted By: argv0

I think his point is that without proper data structures, the api for xml parsing would be pretty ugly.

howabout this ?

$xmlopen(file|url ;optional)
;returns bool

$xmlread(1 1 2)
;path 1 is for the document
;returns 2 name data ;2 is for child nodes number
;returns 0 for path doesnt exist

$xmlwrite(1 1,name,data)
;$xmlwrite(path,node name,node data)

$xmlsave(file) ;optional if u need to save the document

/xmlclose ;clears memory

simple right ?

Originally Posted By: Excalibur

Not quite what you're looking for, but sure this parser will come in bandy
Mpdreamz's XML parser using COM

of course i have come across Mpdreamz xml parser
its great (like every project Mpdreamz did actually)
but its not as handy as this one

there is nuthin wrong with feature suggestion guys am pretty sure everyone would have liked it if its implemented

Also, Rather than COM, Genscripts currently is developing a dll called mChef (chromium browser in mIRC).
Why i'm mentioning this, is that it allows you to use javascript (V8 engine) to parse XML.

Might be (is?) a better alternative to COM

http://sourceforge.net/projects/mchef

If you're just looking for JS, there's already Javascript4mIRC at http://kthx.net/clb/js4mirc which would probably be easier to use than mChef. You could also use ruby4mirc or python4mirc (or even just straight C++)-- but I don't think that's the issue here.

Code:

$xmlread(1 1 2)

Paths aren't only expressed as a set of indices-- that's pretty useless when it comes to XML, in fact. The power of XML is the semantic involved in tags abstracting the structure as a set of indexed data (/html/head/title is more robust, meaningful and accurate than "1 1 2"). The important part of the API would be making a node's children enumerable, not simply getting at a specific node. If we're only talking about accessing a specific node (the 2nd element of the 1st child of the root), XPath works much better. However XPath is limited because it doesn't solve the enumeration problem. Yes, XPath can return collections (//li, for instance), but how to "return a collection" in mIRC brings us back to the same problem I discussed above.

Using your $xmlread how would i take node $xmlread(1 1 2) and then loop over its children? That's the question the API would need to answer.

Why don't you people try writing a XML parser w/ mIRC's native language. At first just don't concern yourself w/ performance. You learn the structure. What's the point of XML if you don't know how to take advantage of it. Writing your own parser will teach you this.