For now I also think that IKVM is the way to go. This will be faster and won't require a lot of effort. Since we do not have enough resources working on Drools.NET full-time, it will be dificult to keep up with Drools. I agree with Denis, that right now having rule authoring support in Visual Studio is more important than porting the entire Drools from java to .NET. Once we have a working project that is being used widely then, as Mark said, JBoss could put a full-time resource on it. Then we can think of porting the entire Drools to .NET.
-Ritu Denis Ahearn <[EMAIL PROTECTED]> wrote: I also vote to continue with the IKVM approach for Drools.NET. I especially like the fact that by being based on the same binaries as Drools, Drools.NET benefits from any new features added to Drools, and also benefits from all the testing and QA work that's gone into a Drools release. A native Drools.NET would have to do all that stuff itself, not to mention the work required to keep a native Drools.NET in sync with Drools as it continues to evolve. I would rather see the extra effort put into things like adding rule authoring support to Visual Studio, similar to what the Drools team has added to Eclipse. As far as the issue about exception handling being slower under IKVM, is that really an issue? Exceptions shouldn't be used for normal flow control. If a program error occurs, the last thing a user probably would care about (in my opinion) is the extra time it takes for the exception handling to execute. Denis --- Mark Proctor wrote: > Yes we can turn certain parts of core into > factories, to make it work > better with .Net. One of those will need to be > PackageCompilationData - > which is responsible for the compiled code and > classloaders. Someone is > going to need to do some research on how we can do > runtime compilation > of code, wiring it up via reflection, and then > making sure we can drop > it - without getting memory leaks. I still think we > should leverage JCI > to try and promote a common parser API, this later > work will benefit > other java/c# integration projects. > > 3.0 works much like 2.5. In that we compile a Class > for the rule. Each > predicate, returnvalue, eval and conseqeunce is a > method in that Rule. > Each method then has a generated and compiled > Invoker class. The invoker > class is wired up to the Rule with reflection. So if > I want to call a > consequence I call the Invoker which is generated to > prepare the data > and call the consequence. If I want to drop the rule > I simply delete > those classes and reload the classloadser - all > classes, the byte[], are > in memory, so no disk work. if I update a rule it > drops the classes, > reloads the classloader and then re-wires the Rule. > > Mark > Chinmay Nagarkar wrote: > > I'm sold! :) > > > > If you really get right down to it, we making a > design choice with > > incomplete data and no comparitive examples of > success/failure. > > > > We have to stay flexible and minimize risk of > failure (to deliver and > > maintain Drools.NET). Keep one foot in IKVM, one > foot in .NET. We can always > > shift the weight to stay balanced. > > > > I feel that continuing interest and coordination > across the .NET and Java > > teams will be critical. > > > > -----Original Message----- > > From: Mark Proctor [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, April 19, 2006 8:18 PM > > To: Chinmay Nagarkar > > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; > > Michael Neale; [email protected] > > Subject: Re: .net support > > > > I've been chatting to the IKVM guys. dynamic > classes is a one time hit, > > so no problem there. The overhead is in the > exception hangling, most > > other areas are fine; .Net has slower exception > handling than Java > > anyway, IKVM adds further overhead to this. > However we have minimal > > exception handling in the core runtime which I > feel is management; > > jereon has shown some ways to avoid the really > large hits. The one > > caveat, and this is true even with a native port, > .Net 1.0 has an > > infexible ClassLoader system compared to Java you > cannot reload classes > > - you have to dump the entire appdomain - which > isn't doable. .Net 2.0 > > apparently allows you to add/remove methods, so > maybe we could work > > around that. > > > > Jereom has more work planned on speed, so IKVM > will only get better; if > > performance is only 5% on averag worse - I don't > think that justifies a > > native port - which will be a huge undertaking, > especially as our > > platform grows. > > > > Mark > > > > Chinmay Nagarkar wrote: > > > >> We should investigate moving additional > code/components to .NET that are > >> deemed to be performance killers. Unless that's > impossible within the > >> constraints of the technology and available > resources, my vote is to > >> leverage IKVM. > >> > >> > >> > >> -----Original Message----- > >> From: Mark Proctor [mailto:[EMAIL PROTECTED] > > >> Sent: Wednesday, April 19, 2006 1:50 PM > >> To: [email protected] > >> Cc: [EMAIL PROTECTED]; > [EMAIL PROTECTED]; > >> [EMAIL PROTECTED]; > [EMAIL PROTECTED] > >> Subject: .net support > >> > >> I havea updated the blog with some thoughts on > .Net support and IKVM. > >> > >> > >> > > > http://labs.jboss.com/portal/index.html?ctrl:id=page.default.blog&project=jb > > > > > ossrules&from=1&link=http://labs.jboss.com:8080/projects/jbossrules/blog/sta > > > > > tus_of_IKVM_and_Drools.html#http%3A%2F%2Flabs.jboss.com%3A8080%2Fprojects%2F > > > >> > jbossrules%2Fblog%2Fstatus_of_IKVM_and_Drools.html > >> > >> Mark > >> > >> > >> > >> > >> > >> > > > > > > > > > > > > > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
