A fellow contributor to rainbow (Jes) loves xml and has introduced me to eXist. Summary below:
eXist is an Open Source native XML database featuring efficient, index-based XPath query processing, extensions for keyword search, XUpdate support and tight integration with existing XML development tools. The database is lightweight, completely written in Java and may be easily deployed in a number of ways, running either as a stand-alone server process, inside a servlet-engine or directly embedded into an application.
Depending on how the database engine has been deployed, eXist offers several interfaces to application developers, including HTTP, XML-RPC, SOAP and WebDAV. Java developers should have a look at the XML:DB API, which provides a common interface to access XML database services.
He is currently using it via soap. For those of you who cannot run a java app on their hosting account, there is a way of having eXist and other java apps run under the .Net runtime (Via IKVM):
What is IKVM.NET?
IKVM.NET is a JVM for Mono and the Microsoft .NET framework.
What do you mean by JVM for .NET?
The goal of IKVM.NET is to be able to run any Java existing application and to allow for as much interoperability between .NET and Java code as is possible.
IKVM.NET consists of several parts:
- ik.vm.net.dll: The VM runtime and all supporting code. It contains (among other things):
- Byte Code JIT compiler/verifier: Just-in-time compiles Java Byte Code to CIL.
- Object model remapping infrastructure: Makes System.Object, System.String and System.Exception appear to Java code as java.lang.Object, java.lang.String and java.lang.Throwable.
- Managed .NET re-implementations of the native methods in Classpath.
- classpath.dll: compiled version of GNU Classpath, the Free Software Foundation's implementation of the Java class libraries. Note that Classpath isn't part of IKVM.NET, but it is used by IK.VM.NET
- ik.vm.jni.dll: Managed C++ assembly that implements the JNI interface. This is an optional part, only required when an application uses it's own native libraries. This will not be required for pure Java applications, this is important because this code will only run on Microsoft's .NET implementation.
- ikvm.exe: Starter executable, comparable to java.exe
- ikvmc.exe: Static compiler. Used to compile Classpath classes into a .NET assembly. In the future it will also be possible to compile Java applications and libraries into .NET assemblies.
- netexp.exe: A tool that generates stub class files from a .NET assembly, so that Java code can be compiled against .NET code. IKVM.NET understands the stubs and replaces the references to the stubs by references to the actual .NET types.
- awt.dll: Very limited and broken implementation of a few AWT peers. This is a low priority issue for me.
But there is one problem:
eXist throws an exception because of a missing constructor in GNU Classpath's java.io.File class.
The Classpath's URI support is lacking in some areas. So if anyone is great at Java and has some spare time for a project in order to implement it, please see http://www.gnu.org/software/classpath/
Unfortunately my java experience is not very deep which is why I was seeing if someone else was interested in this.
Either way you should check out IKVM and eXist.
If you like eXist you may also want to look at:
XMLDB.NET is an implementation of the XML:DB Core Level 1 specification and exist providers for .NET. You can download the current version via the links below.
XML:DB (and the EXIST provider).
You can read the README online.
Hope you find the software interesting.
The latest version of Rainbow has been released on sourceforge:
What's New since 126.96.36.1993:
- More modules now reside within their own folder
- Lots of bug fixes
- Upgraded Free TextBox to 188.8.131.52073 and Free TextBox is now the default html editor
- Rainbow now uses the Rewrite.Net Engine as the Url Handler which allows you to build custom rules on how to handle urls (Url builder has also been improved). This improves performance and search engine friendliness. Legacy urls are still supported via a legacy rule so that search engine results are not broken ;-)
- TabStripDetails has been improved and the slow part of the code has been removed ( A 20x performance improvement has been reported).
- KickStarter support has been added www.kickstarter.net and rainbow contributors have received a free license (Thanks Mike!)
- Cory Isakson, added WebCompile Feature so all aspx pages are compiled after the first aspx page has been hit (Thanks to Paul Wilson's article on asp alliance).
- Fully localized Site Settings and Module Settings by James.
- Removal of Legacy Files
- A Windows Script Setup file has been added: Setup\Scripts\setup.wsf making setup an easier process.
- More and more people have been contributing to Rainbow, not only code but also documentation (Thanks to everyone who has contributed):
New Documentation: Webmasters Handbook by Tilli
New eCommerce 'Product Module' user guide by Thiery
Other documents have also been updated: http://rainbow.duemetri.net/Rainbow/go/rainbow/3405/en-US/DesktopDefault.aspx
- The Rainbowportal.net website has been updated and is now running version 184.108.40.2066
- A Module Gallery Module is currently being worked on to allow people to find out more and download modules (currently in beta).
- A Themes and Skins Section has been added to the rainbow website to allow people to share/showcase their work.
- Jakob has created a Beta Version of MDF (Module Data Filter) (Not in latest rainbow release as it is beta):
"I did this code/helper because I got tired of not being able to display data from one module in another module. So I created a general solution: MDF. Getting a module to use MDF is done in 30 minutes.
To get code: See Download tab at http://www.rainbowportal.net
Use MDF with modules that displays list of items, e.g. Links, Announcements, FAQs,
Tasks, Contacts, Document, Events and Pictures. MDF controls the items being listed with these settings:
DataSource: "This", "All" or "List"
Max Hits Represents the number of items returned by MDF
Module List: List of module ID's. e.g.: 20242,10243.
All Not In List: If DataSource is "All" this can exclude modules
Sort Field: A list of all fields from the core item table
Sort Direction: ASC/DESC
Search string: typically a word like "fish"
Search field: All fields or a specified field from the core item table"
- Cory has kept up contact with Shaun from DNN to see where each solution can complement each other. Jeremy White (From DNN) is working on a Rewrite.Net Rule for DNN and has been working on a Url builder for DNN (Hopefully from here more components can be built together to avoid re-inventing the wheel and benefiting from each team's experiences).
- PDC - Birds of a Feather : Rainbow/DNN/IBuySpy has been approved as a topic http://www.ineta.org/bof/Default.aspx
- Mark has done even more improvements to the rainbow portal site and Graz will soon be producing a regular rainbow newsletter.
A complete history of the changes made to rainbow so far can be found here:
I was just reading Miguel's blog and found the following link:
The CLI-UNO language binding allows to write UNO client programs for OpenOffice.org with languages like C# or VB.NET. The language binding will probably become part of OpenOffice.org 2.0. Until then one can use an OpenOffice.org 1.1 and the language binding package which is separately available from this page.
I like openoffice and have been using it for a long time now. I still have/use MS office and it is a lot more polished but I like knowing about alternatives out there and this news is definately good as it means I'll be able to build .Net apps that tie in with either office package (depending on what the client has).
If you have never used openoffice I recommend you give it a try. It's always a good idea to know what's out there (especially now that they will be adding .net support).
I've heard xml spy is great and I've seen it in action and it is very powerful. But for those companies that cant afford it, there is hope.
I've just come across this link that I saw on a post in the xml forums at www.asp.net (Thanks Joteke).
- Color-coded XML, DTD, and XSLT editing
- Check well-formedness and validate
- Stylesheet testing with almost any XSLT engine
- XPATH testing
- Customizable "Code Bits" library
- XML formatting via Tidy
- Small download, small footprint
I've installed it and hope to give it a test run at some point. If other people try it please post feedback here to let people know +/- points.
I know, quiet for over a month and now three posts in 30 mins.
Since this is a limited free offer I thought I would let you know about it before it expires.
Mycos are offering their .Net charting component for free in order to gain awareness. It seems pretty good so I would recommend people check it out.
Just seen a comment about my previous post regarding Rainbow and noticed that the formatting had vanished.
My default browser is Firebird and everything seemed fine as it was in the textbox. Unfortunately this was not the case and everything became one giant paragraph. If you got that version, this is just to let you know I have updated that post via IE and it now looks fine.
Sorry about that......
Hi all, It's been a long while since my initial blog....sorry and a lot has happened (went on holiday and I've been busy at work which is why I haven't had a chance to blog).
Anyway I've been following a thread on the Rainbow forum at www.asp.net and what started off as a quick response quickly grew.
To see the thread (about modules within Rainbow and whether or not the number of commercial modules in DNN is a good thing) please go here:
Anyway here is what I just said:
You have to love these discussions
I have been contributing to rainbow since it started in November, but please don't take my view as the official view (This is just my opinion).
I follow DNN's progress and I just installed the latest version to see how it worked. I think they have done a great job.
Rainbow is still rough around the edges but I prefer it (I won't go into the details etc as that has been discussed on the very many "which portal should I use" posts).
This is how I think we (the rainbow project) should (Take note: "should" not "will") proceed and for those DNN contributors out there, they might want to consider this also:
* You have a team focused on the core (get standards in place, extra core functionality etc)
The core should be made up of different projects/components/dlls.
E.g. There are currently 3 seperate dlls for core functionality (plus the rainbow.dll):
1) Esperantus (Language Handling)
2) Rewrite.Net (Url Handling)
3) A Schedular project to allow core code and modules to schedule activities.
Ideally these projects can work together or independantly and are not 100% tied into the portal (Esperantus and Rewrite.Net can be used by standard websites or even DNN).
With seperate projects DNN & Rainbow developers "could" work together on some aspects (esperantus for example) and still have their own portal implementation (e.g. use a different url handler as the way rainbow & DNN handles urls is different).
This saves a lot of time by not re-inventing the wheel (It would also mean developers could just use parts of either framework when something custom was needed [neither rainbow nor DNN suits every situation, but sometimes certain parts of the framework could be used....e.g. Esperantus]).
* You have a team focused on Free Modules (we currently have some people doing this with Ender and Jakob doing a great job as project co-ordinators).
This helps insure that there are useful modules that keep in sync with the portal (As the module team stays current with what is happening to the core). It also means people can achieve more at a lower cost of entry.
Currently all modules are included in the core, personally I think in the future it would make sense to seperate them:
- One project - Core framework made up of multiple building blocks
- Second Project - Free Modules.
With regards to the second project whether or not this should be 1 solution with multiple projects (one for each module - Each module contributor is lead co-ordinator for their module and they in turn are co-ordinated by Ender and Jakob so that they keeps in line with future core releases) I don't know. I think that it might be a good idea but that is still to be discussed.
* I agree with the post that the reason why there may be more commercial modules for DNN is because of the size of it's user base. But I also think that it is because we haven't released a final V1 release (No point building a commercial product for a moving target).
Personally I think people creating commercial modules to earn some extra money (for single developers or a small group) or as a business (A company dedicated to selling modules) is fine and it gives people more choice (Some commercial modules may offer support and offer functionality not provided by the free modules).
I'm moving back to London in November after living in Denmark for a year in a half and I plan on creating a commercial module at some point to earn a bit of pocket money as I settle back into London life.
For my commercial module (I haven't even started it yet but I thought I would use it as an example) I plan on doing the following and I think it's a good idea for either portal project:
1) Once I have developed and tested it against a solid release e.g. DNN 1.10 or Rainbow V1 I will give a license to all portal contributors (i.e. they can use it on unlimited websites for their site or their client's site but they can't simply resell it as a module) because without the people who work on the core I wouldn't have a portal for my module and without the people who contributed free modules my audience audience wouldn't be as big etc. Of course I would also offer it to those that contributed documentation etc as their contribution is just as important as the others.
Why do this......
a) It's a way of saying thank you for their time and effort.
b) If all other commercial module developers followed suit, it would be an added incentive for additional people to contribute their free time to the project, which would hopefully mean a better product in the end for everyone.
2) It's true that commercial modules may not keep up with the opensource ("free") ones with regards to the rate of change etc. So for commercial module developers I would suggest the following idea:
a) Sell & support your module (I'm not saying they don't already)
b) Give a free license to contributors (as mentioned above)
c) If people like and use your module and would like to contribute bits of code to it in order to improve it, give them credit for their contribution and give them the next upgraded release for free (Or offer them part of the proceeds depending on how much code they have contributed....entirely up to you). This will not necessarily mean that it will evolve as fast as an opensource module, but it could mean that it may grow faster than one which is simply commercial (a hybrid of sorts).
Anyway these are just my thoughts that I thought could apply to both projects.
Let me know what you think and please be gentle
Let me know what you guys think either through the thread, blog comments or email.