October 2004 - Posts
While hunting arounding for an implementation of Zlib (namely RFC1950 and RFC1951) I have found for the second time something present in Java but not in .NET. It does however seem that its
possible with Sharp Zip and this
post indicates its also possible using J# (
more here). Not confirmed if Sharp Zip meets the RFC requirements, prehaps someone who knows more on the subject than me could confirm it?
Got a coding session ahead of me tommrow night (Saturday) while I can continue to work on a few ideas, I don't doubt it will be Sunday before I stop.
Also got a quick heads up on a
SSL wrapper class for Open SSL written by Pieter Philippaerts & the folks at Mentalis.org, the CLR/FSL lacks behind Java in that it has a set of classes for SSL, would be great to see this as an offical part of the CLR/FSL.
One of my fave Flash and .NET bloggers
Robin Debreuil has joined Xamlon, this is great news, way to go Robin ! Gonna be a cool gig for you.
If your using VS 2002 and looking for a XML comments widgit then look no further. The
VBCommentor VS 2003 powertoy is an opensource project and I can confirm it works well on VS 2002. You will need to join the project so you can access the source, from there either download the source files and rebuild the solution file or download the VBCommentorSource.zip file (you can then compile from here or update the solution with the files from source control).
Been some great discussions on the Laszlo dev list, in terms of a .NET port I have raised the following points
- Ability to code in any .NET language, take advantage of any existing assemblies/code and make full use of the FCL.
- Backwards compatable with LZX to output to Flash but also the abilty to output to winforms, swing or XAML etc.
To achieve these goals I have suggested the source will need structuring so we can build the core in Java and then build ontop of the core to build in either Java or .NET functionality. Still waiting on the outcome, will be interesting to see what happens, either way I have asked for folks to start thinking in roap map terms.
I have also started thinking about the network layer in Laszlo. Largely its a high level layer ontop of a common communications layer. I would see the rpc being the low level core with the other tags built ontop, in the core on layer approach I have suggested a common API could be created so you could plug into the core to create other tags. In this way you prehaps add .NET Remoting or RMI etc. The SOAP tag could prehaps be extended so that we could add other parts of the WS-* stack, in this tag we could go for standards and runtime support. That is support the various ways the runtimes support SOAP, for example in .NET the way the way datatables are serailized and deserailized in .NET. If the SOAP formatter was a core protocol then with the layer it would be able to add to and take from the SOAP packet and in this way we could support the various ways the runtimes support SOAP. Just some ideas :)
Busy week ahead of me, some stuff I want to work on, idea's and such.
XML DevCon (aka SellsCon) is well underway, I know
Robert is having a good time. I would love to be there to wax it with the Avalon folks, but instead on a week long automated functional testing software course, hey ho. Some very odd pictures coming out of the place, mostly this
one and this
one (Rory just creases me up :)
update:
hey I made the villa sells, and my post has the least techy title :P
Time to dig into some details, comments welcome. This is from a recent post on the laszlo dev mailing list, I have added some annotations.
The question was how can a Java code base be used for the JVM/CLR. One suggestion was IKVM, while this project rocks I don't think it would be a good match in thise case, heres' why. Maintaining combined Java/.NET code bases can get tricky. I have seen in the past that the code base core be written in Java and then compiled to IL using J# for the CLR or to Java bytecode for the JVM. This approach while costing some Java features means that your not bridging the code nor layering the code. A code layer would be a feature such as the IKVM which is a Java VM that sits ontop of the CLR. If the code can be compiled to IL or Java bytecode then you are taking advantage of all the benefits of each runtime. The features that you lose in such a code base you can then add to depending on the runtime you target.
That is when the core is compiled you can then add features that is unique to the runtime. For example these features could be built in C# for the CLR (or any other IL targeting compiler such as VB.NET or if python is the preferred choice IronPython) and allow features unique to the CLR. Or if Java is the target then these features could be built in Java and take advantage of the JVM. While the core would be one code base you will still have two code bases for each runtime, but it will mean that features unique to the runtime will be allowed.
I wanted to make clear the point that follows. Developers using the CLR will want features of the CLR, they will want remoting and the ability to reuse assemblies and legacy .NET code without any drop in features. The same goes for Java and the JVM etc.
Its very important that the full power of each runtime be used for each code base, when a coder is targeting the CLR or JVM then they expect to be using the full power of those runtimes.
A recent post mentioned that the the compiler was written in Jython but being rebuilt in Java, the fact Python is being used could help, my reasons....
On the python note, I know it was mentioned that the compiler is being rebuilt in Java from Jython (Python on the JVM) but if the language was to stay at Python then IronPython could be used to retarget to the CLR and one code base remains.....just a thought.
Its great that some thinking about running on two runtimes is going on, details do remain and the more folks chime in with their thoughts the better.
John has a great post that LCG has been discussed on the IronPython list, Joel and Jim have weighed in with info on LCG. The point that John makes is a very important one, with eval generated code it cannot be reclaimed in a GC sweep in LCG it can be. So languages that dynamically generate methods
can be collected. I think that Jim does intend to work LCG into a version of IronPython,. will be interesting to see what difference it makes. John also notes Jim is looking for a SDE to work on dynamic languages in the CLR, that just rocks.
My recent Laszlo and .NET post got some great comments, the interest level is at the moment only at the "curious" level but I do think that folks within Laszlo and the .NET community would be willing to start a .NET project. David Tempkin left a comment wondering on my thoughts on a few things so here is my thinking. The server and compiler could be seperate, that would mean that SWF could be created with out the LPS but where does .NET fit into that. Its really about services and your audience.
When a NET development team look at something like RIA and (for example) the LPS they are asking, how can I reuse my exisiting legacy .NET code, APIs and assemblies? How can I reuse my programming skills, while its true that ActionScript is a good match for C#/Java coders its not close to VB.NET and someome who ignores those programmers does so at their peril, lets not forget WinForms can be coded in any CLR language. They are also asking how can I use serialized data, be it from file or from a web service/ADO.NET or remoted. Lastly they are asking, Longhorn is coming, Avalon and Indigo is something we are steering towards, what can a RIA do for me now that I reuse with Longhorn. Much of this thinking is powered by time and money, it costs both to retrain and reskill a team, so anything that goes beyond the standard .NET model (for example winforms or webforms etc) even in big teams (who would have to fight hard to get the budget and prove beyond doubt the ROI) will suffer.
David asked me about compiling to the CLR rather than a SWF and VS integration. Compiling to the CLR from a XML syntax is indeed possible, what this actually would mean is how can I generate a Winform or WebForm interface from a XML syntax. This is of course possible (
Xalmon does this right now with XAML). If VB.NET/C# were usable then the webform/winform could be generated and passed off to the VB.NET/C# compiler. No ActionScript compiler currently exists for .NET, in the longterm it would be best to create one (it could in theory be adapted from the Microsoft or Mono JS compiler) but in the short term it could be compiled to C# and then passed to the C# compiler (2nd stage compilation no one likes but short term would work).
VS.NET has the API to host any compiler, debuggers would be tricker to do but could be done (I would recommend that we use the CLR debugger hooks to create a Laszlo debugger for .NET), we could with time and effort certainly run and debug Laszlo apps in VS.NET.
So there are some summary thoughts, many of the details and thinking still remain.
More Posts
Next page »