One of the things we've wanted in Quanta is handling of object syntax and local functions and objects in projects. This is currently in work now. Andras has the first implementation in CVS that reads objects and functions in the same file. The objective is to make it work for any linked file. Interestingly this involved new tagxml information so that other PHP objects can now function and it also gives us a means to cache this information for the project. Obviously it will take into account any changes on your code.

Kommander is undergoing some even more interesting developments and I wanted to write to address them and deal with the issues up front. When we developed DCOP functions for Kommander including string, array and file functions people were concerned we were inventing a new language. Not only was that not our intent, but we did not see a few DCOP scripting functions as a language. Currently we are testing a full parser that will be introduced into CVS any day. We have a lot of little details to work out. The parser will enable local variables, nested structures and more. No doubt people will be even more concerned this is introducing a language. I suppose we are, but the thrust here is not to create a new language. It is reach to several specific goals. We want to create a simple means to accomplish basic tasks that is easier than something like bash and have something that is universally available for distributed applications. The other thing we want to do is to empower other scripting languages that are not DCOP enabled. The new parser will do as much to help people use PHP or Rexx as it will help to develop without them.

Kommander's mission is to be a language neutral tool. This works in many cases and creates a huge problem in some. Any time you initiate a process with another scripting language (Other Scripting Language) it only has access to the state of widgets and values at the time it was launched. Creating logic structure interacting with Kommander widgets requires integration of the OSL or DCOP bindings. Both processes would need to know where the other was somehow. In application this is something that only comes up in a small percentage of uses. The way around this is to continue with Kommander's abstraction model. Kommander handles the GUI and is not equiped for extensive data management and other tasks that OSLs are well suited for. By being able to create logic structures with Kommander as well as call scripting functions that are run with OSLs this integration can be accomplished without making a huge task for us. Of course you can call an exec command in an OSL and use console DCOP to message the window.

What all of this means is that Kommander will be vastly more capable, along with other things we're working on, and that when you set out to do a task with it you will basically choose your approach based on both language preferences and the type of task. If you want to use an OSL without DCOP bindings you can do so with just a little structural logic from Kommander's language if you need live interaction. These decisions on our part are based on our experiences attempting to provide a tool with unbeatable ease of use and the problems we encountered reaching our objectives.

Overview:

kpdf, the KDE pdf viewer, shares code with xpdf. xpdf contains a buffer overflow that can be triggered by a specially crafted PDF file.

References:

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1125 http://www.idefense.com/application/poi/display?id=172&type=vulnerabilities