So much to talk about, so little time, but none-the-less, let’s get this party started ;)
Amplee, IronPython, ASP.NET, WSGI, AtomicXML, and Xameleon Update
So both Sylvain and I have been jamming away at the integration of Amplee, IronPython, ASP.NET, WSGI, AtomicXML, and Xameleon. Attempting to merge together such a cross-section of various technologies, as you can imagine, has been interesting. None-the-less, we have things working pretty well at this stage, and have in the works an update to last weeks OSS XML Weekly Roundup, in which I will be providing all of the juicy new details in regards to progress. That said, if you would like to start peaking through the curtains to see what we have in store, please feel free: http://extf.googlecode.com/svn/branches/
Sylvain has already finished the first tutorial as it relates to getting Amplee running via IronPython and WSGI, and when he comes back online here in a few hours, we plan to continue forward fine tuning the API we are collaborative working on to integrate AtomicXML with Amplee via the Xameleon XML processing engine. And has he has pointed out at the bottom of the above linked post,
Microsoft .NET and IIS ¶
Soon :)
I actually finished the integration with IIS yesterday, and while getting things to work on IIS 6.0 is pretty straight forward, due to the inability to map wildcard matches to a specific handler (you can match wildcards as they relate to file extensions (e.g. *.foo), but not as they relate directly to paths) on IIS 5.1, and given that IIS 5.1 is the default IIS version that ships with Windows XP, it requires a bit more work to get things functioning properly, so at the moment, I am holding off writing things up until I have few extra minutes to get things working properly on Windows XP/IIS 5.1.
Of course, I have put a bit of time into developing a self-hosting solution via Mono’s XSP ASP.NET implementation, and while it still needs a bit more work, and a bunch more testing, this will definitely provide for a nice alternative for running a local instance of the above combined code base on top of Windows*, Linux, Mac OSX, and/or any other platform supported by Mono.
Please stay tuned for more details in regard to all of the above.
So, to my list of *MUST HAVE* OSS projects for the week,
Prebuild
Prebuild is a cross-platform XML-driven pre-build tool which allows developers to easily generate project or make files for major IDEs and .NET development tools including: Visual Studio, MonoDevelop, Sharp Develop, Autotools, and nant.
I’ll keep this short: I have wanted this tool for SOOOOO LONG!!! It’s been available since the middle of last year, apparently, but I only found out about it after updating my local copy of the project that follows. None-the-less, this project has me smiling in ways I can not even describe.
MonoTorrent
MonoTorrent is a Mono based bittorrent library that offers an API for bittorrent for developers on the .NET platform.
I would be doing this project and injustice by not spending the proper time writing about all of its wonder-fullness. As such, I am going to allocate and entire weekly roundup post to it to ensure space for proper coverage. In the mean time, please don’t hesitate to visit the above linked SWik.net project home for more detail.
XQuery, Stand-Alone Documents, and the .NET Platform
As recently reported, MSFT is seeking comment on whether or not support for querying stand-alone XML documents via the recently standardized XQuery 1.0 specification is of interest to the XML development community at large. Of course, the informed hacker is quite aware of the fact that XQuery support was at one point a planned inclusion in the release of .NET 2.0, with CTP releases through January, 2005 including support for the pre-final-rec specification available for building and testing against. The reason for choosing not to continue forward with support was based on various factors, some internal, some external, and nearly all of them relating to fact that it was obvious the final recommendation would come well after the final release of the .NET 2.0 platform.
But setting the above request aside, something recently occurred to me,
via http://www.mono-project.com/XML#Mono.Xml.Ext
Mono.Xml.Ext
(IMPORTANT: There used to be System.Xml.Query.XQueryCommand class that implemented XQuery, but now Microsoft dropped it for .NET 2.0. So we moved them out to external assembly named Mono.Xml.Ext.dll, but I haven’t changed thing so much when I just extracted them. Thus, this section is kept as is, and basically old stuff.) Mono.Xml.Ext.dll contains mainly XQuery implementation, and some utility classes. XQueryCommand implements XQuery. XQuery is a new face XML document manipulation language (at least new face in .NET world). It is similar to XSLT 1.0, but extended to support XML Schema based datatypes (and it is not XML based language). It is similar to XPath 1.0, but it can construct XML nodes. It has no complicated template resolution, but works like functional languages. Under MS.NET, XQuery implementation is mainly in System.Xml.Query and MS.Internal.Xml.
Of course, via Saxon on .NET, you gain XSLT 2.0, XPath 2.0, and XQuery support, and you gain it from the most experienced, respected, and without argument, the most capable developer in this space: Dr. Michael Kay and his company: Saxonica. None-the-less, as is the case with XSLT and XPath 1.0, each processor has both its benefits and disadvantages.
Okay, so Saxon doesn’t really qualify for any real disadvantages, one (all-be-it small) disadvantage is that it isn’t native to System.Xml, and therefore you can run into a few issues here and there when it comes to things like document-type conversions, and there is a bit of a performance disadvantage when compared to its Java counterpart due to ~5% performance hit you will encounter when working with the Java libraries via IKVM.GNU.Classpath.dll as opposed to the native System.* libraries on .NET.
But regardless, there are thre primary advantages I see to getting involved with the development of Mono’s XQuery implementation,
* Native to System.Xml
* The more XML processing and querying solutions, especially when it comes to the next generation of XML processing, transforming, and querying technologies in XSLT 2.0, XPath 2.0, and XQuery, the better.
* Both XQuery and XSLT 2.0 build from the same foundation: XPath 2.0
The final point is probably the most important, in my opinion: Help to finish out the XPath 2.0 implementation, and in doing so make it that much easier to begin work on a native XSLT 2.0 implementation, something that seems imminent given Microsoft recent announcement regarding work moving forward on their implementation.
Want to get involved? If you have the means (e.g. knowledge, time) I would encourage you to do just that. Please visit the “Contributing” section of the Mono-Project’s home for more information.
nuXleus Project Update
[nuXleus@SWiK.net]
Speaking of Mono, from a post to the Mono-Project blog from last Friday,
Mono 1.2.3.1 Released
We have issued a bug fix release for Mono 1.2.3 that contains only critical fixes to bugs that people have reported for Mono 1.2.3.
Details are available here
As I’ve already made fairly obvious, the nuXleus project is firmly founded and built on top of a Mono foundation. While I was going to simply ignore the above release for now, and work in finishing out the final pieces of the next nuXleus project release based on the 1.2.3 build that I committed to the project repository last week, one of the problems I ran into recently meant that I wasn’t going to be able to include the latest release of IronPython Community Edition due to a problem with the compilation. That said, via the above linked “Details”,
* Fix IronPython 1.1 alpha 1 Compilation (80749).
As it turns out, this is exactly the problem that I was seeing, and with the fix firmly in place, was able to build out the latest IronPython Community Edition from the repository based on the 1.1 alpha code. Of course, as was reported yesterday in an entry to my Windows DevCenter blog, IronPython Beta 1 was released on Wednesday afternoon which means that its time for another rebuild.
Of course, at the very core of the nuXleus project is the ability to provide XML-based communication services via a virtualized instance of Linux running on a primary host. If not obvious, the work that Sylvain and I have been doing in the APP/Atom space as of late, while purposely disconnected from the core nuXleus development trunk, sits at the very core of nuXleus from a feature perspective. In other words, while keeping it disconnected will ensure that all of the related technologies can function independent of nuXleus, it’s still a major part of what this project is all about, and as such, until such time as we have things more finely tuned and ready for an initial combined distribution, then attempting to push nuXleus any harder than needs be to keep in sync with the APP/Atom-based work, really doesn’t make a whole lot of sense.
One way or another, however, I will be getting the latest build together and readied for release just as soon as it makes sense to do so. So please stay tuned for the announcement here on this blog when its ready to go, and in the mean time, please forgive me for continually pushing off the next release. It’s coming together nicely, but there’s still more work to do, so as mentioned, please stay-tuned.
Coming back to the topic of XQuery, I came across the following project fairly recently which most definitely seem worth sharing,
XQilla
via http://xqilla.sourceforge.net/HomePage
XQilla is an XQuery∞ and XPath 2∞ library and command line utility written in C++, implemented on top of the Xerces-C∞ library. It is made available under the terms of the Sleepycat licence and a BSD style licence.
Seems *REALLY* interesting, *ESPECIALLY* when you consider,
http://freshmeat.net/projects/xercesc/
Xerces C++ is a validating XML parser written in a portable subset of C++.
NOTE: If not obvious, its the “XML parser written in a portable subset of C++” that has me suddenly realizing: “Hmmm… This could really become useful for building out a high performance X…” and that’s where I have to cut myself off. I’ve already got WAY TOO MANY unfinished “Hmmmm”’s floating around. I really can’t afford the time for any more.
That said, if you do, and you have the interest… “Hmmmm…. ” ;)
Daylight Savings Time, TimeZone Data, and You
I recently received an email from developerATresponseDOTmicrosoftDOTcom which began with,
In 2005, the United States government passed the Energy Policy Act of 2005. This act changes the start and end dates for Daylight Saving Time (DST) as of spring 2007. These changes may impact the way applications run. Microsoft is releasing an update for Windows through Microsoft Update that reflects these changes.
Developers who use the .NET Framework may find their applications affected if the application uses the time zone information for historical purposes or if they have derived custom classes from System.TimeZone to provide custom time zone information. The standard System.TimeZone class provides a managed wrapper for the underlying Windows Operating System time zone functions.
Which reminded me of a recent post made by none-other than the legendary Chris Sells, [see bottom of linked page to understand the connection]
TZ Data to XML Project from Chris Sells
In a recent post to his blog, Chris Sells writes,
A long time ago (2000), I was fascinated with turning a phone number into a time zone so I could tell what time it would be somewhere before I called and woke anyone up (this happened too often : ).
a bit further down he continues with,
At the time, they had a custom format for the data (and they probably still do, as far as I know), so I wrote a utility to translate the tz format into XML for easy parsing. I literally haven’t touched the tool since, but with the recent time zone law changes in the US, I thought folks might be interested. Enjoy.
If you follow the above “.. tz format ..” link, you will find links to the source (PLEASE NOTE: please do not redistribute without first obtaining permission directly from Chris), samples of the XML output, as well as the following list of TODO items and a request for help in finishing them up.
Yet To Do
* Namespace support.
* XSD support.
* An XSLT to translate back to native tz data format.
* An XSLT to output popular data needs, e.g. all the zones, all the rules, etc.
* An updated zic to use the new XML format instead of the existing format.
* Unix port of tz2data (I’ll need help on that one).Help!
Unfortunately, I’m but one man. If you’d like to help on any of these projects, let me know.
So here’s the thing: Helping to finish up the items on the “Yet To Do” list will not only be helpful to quite a few people (such as myself!), but to put it lightly: Getting on {/Chris_Sells[Good_Side|Radar_Screen|following-sibling::*]} isn’t exactly going to hurt your career. ;)
To put this another way, I have two articles, the next release of nuXleus to finish up, several Vibe* (which is how we are now referencing anything related to The Viberavetions Project) related deliverables that need to be ready by Monday morning, two demo’s that are within spitting distance of being finished, and need to be just that: Finished! > *YESTERDAY*!, and yet I have a yellow sticky note on the edge of my computer screen which states: “Hey PhreakBoy: Find time to contribute to tz2xml!”
Not that this needs to be stated, but please feel assured that if I can sneak some time later this weekend, I plan to nail out the requested XSLT files. Unless you beat me to it, of course, something of which, as already specified, I highly recommend if you can spare the cycles.
And with that, my hacker friends, until next time: Enjoy the rest of your dev-days/weekends!
