Quote:

---

Hello,
I think that Kixtart should read and write XML easily without COM just like ini files.

---

Quote:

---

I think we can all agree that if the core language allows you to do a job in fewer keystrokes, and more intuitively, then that is the better option.

---

I understand what you mean however I don't think that we'd all agree on that statement without a few major qualifications

There are libraries available for all sorts of discrete functions - XML, mail, network, maths, forms, 3D graphics, HTTP, HTML, updates, security, SNMP, AD, regular expressions and many more. These provide discrete functionality and are written by experts in their field - at least you'd hope they are anyway.

I don't think that it's a good idea to implement a crippled version of any functionality that is already available - it doesn't make sense. You surely want to use the libraries with the most recent enhancements and bug and security fixes and not have to wait until Ruud can update KiXtart?

The best compromise would be if Ruud added functions that simply called the APIs directly. That however adds no real benefit over loading an XML UDF library at the top of a script with your own ReadXML() and WriteXML() functions to call the APIs.

An XML support library to provide these sort of functions has already been written by board members and is available elsewhere - this will add the simplified function calls to KiXtart without requiring it to be hard-coded into the interpreter.

Rather than duplicating already available functionality into KiXtart we'd be better off improving the interface to COM to allow more objects to be used - event sinks and support for "out" variables for example. Promoting use of COM and providing extensive examples in the manual to help starters and COM-ophobics wouldn't hurt either.

Quote:

---

The best compromise would be if Ruud added functions that simply called the APIs directly. That however adds no real benefit over loading an XML UDF library at the top of a script with your own ReadXML() and WriteXML() functions to call the APIs.

---

Quote:

---

I'm not trying to put words in your mouth, I just don't understand how some duplicated functionality is OK and the rest is not.

---

Quote:

---

The real value of KiXtart to me has always been that it contains core functionality that reduces my need for COM reliance.

---

Quote:

---

If the evolution of KiXtart is moving towards tighter COM integration with nothing new added to the core language then I would say it has no real benefit over VBScript.

---

Quote:

---

If most or all of my scripting tasks will require COM then what value does KiX have over VBScript?

---

I think you have that backwards If KiXtart has access to all the same functionality as VBScript but with a superior interpreter, why would you ever use VBScript? As it is, sometimes I have to use VBScript because KiXtart has only partial support for things like COM automation objects. Now, that really annoys me.

Quote:

---

What draws most new users into KiX as a scripting tool is that it contains a large number of functions that don't require COM. For someone that has never scripted before, figuring out "that COM stuff" can be quite daunting.

---

Quote:

---

The best compromise would be if Ruud added functions that simply called the APIs directly. That however adds no real benefit over loading an XML UDF library at the top of a script with your own ReadXML() and WriteXML() functions to call the APIs.

---

Quote:

---

Since I don't believe that's what you're saying then it comes back to a completely arbitrary decision as to what is included and what is not. So, it really sounds like you're saying not that the language shouldn't support anything that is available via other means but rather you don't think this particular function should be included.

---

Yes, that's pretty close

There are people using well known stuff like IE COM, Office COM and KiXforms as well as more obscure objects. Adding KiXtart functions to access all of this functionality would be ridiculous.

That's why I said that there should be a balance - it's only arbitrary in that Ruud as the arbiter will determine whether it does KiXtart more good than harm in including it, whether the number of people who would use it warrants the effort to include it, and whether it is supportable going forward as the underlying protocols are enhanced.

XML is an order of magnitude more complex than INI file layout. Simple READ/WRITE functions are not sufficient to support the complexity, so my major concern is that support is not bifurcated.

If the end result is some XML files are read/writeable and some not or some XML functionality is available but some not or new functionality provided by XML enhancements cannot be accessed in KiXtart then scripters will need to disregard the built-ins and revert to COM to provide the functionality. This is already happening in a number of areas where the scripters needs are not supported by the built-in functions and we are having to find other methods and it lessens KiXtart.

Quote:

---

And on that point I don't think we'll ever agree.

---

Quote:

---

XML is an order of magnitude more complex than INI file layout. Simple READ/WRITE functions are not sufficient to support the complexity, so my major concern is that support is not bifurcated.

---

I understand that argument completely and largely agree, though IMO the simpler functions would be useful for most scripters most of the time and if they needed more powerful/versatile functions they could delve into the API. An underlying assumption on my part is that these simpler functions could be created by leveraging existing APIs instead of having to build in complicated logic into the interpreter itself, which would necessitate the bifurcation of which you speak. Speaking of bifurcation, I must have eaten something a little off because I've been bifurcating for the last hour or so

As this topic has been pretty much beaten to death, at this point I will follow Richard's lead and I likewise promise not to post on this topic again... and there was much rejoicing...