Forum .LRN Q&A: dotLRN on .NET
multiple independent sources: Will there be a dotLRN port to .NET?
If yes, is there a time schedule (in quarters)
Notice that there's nothing from stopping people from making dotlrn components into "web services" (to use a current buzzword) through SOAP and other protocols that .NET uses. In fact, this is one thing that I'd like to do with some OpenACS applications. There are Tcl modules to do that already.
I want to state this as a matter of public record:
- dotLRN must be made available under an opensource license;
- dotLRN must run on an opensource stack (operating system, web/application server, database);
If I violate (1) or (2), I will resign from Sloan and pay for Neophytos plane fare to come and accept my resignation.
First I would like to clarify that I am going to be posting twice. Once as a member of the Heidelberger E-Learning team and once as a member of the EB of dotLRN.
I start with the Heidelberger subjective view:
I am glad that Roberto finally brought this point up in the governance thread... this rumor has been bothering me for a while (I have been waiting to post because I did not feel it was my place or that I had enough background information). I think these rumors also had a lot to do with some of the tension in the governance discussion.
In Heidelberg we have spent a lot of time and energy looking at different eLearning platfroms and dotLRN has been at the top of our list for a while. Obviously before we could make our final decision in Heidelberg we had to clear up all the various questions that came up that we could not find answers to in the forums or the website. Even though we had contacted a lot of people we decided that it was imperative that we fly to Boston and talk with as many people in person as possible (there were just too many open questions).
The news of potential funding from the iCampus project was one of the things that came up shortly before our trip and was a shock. To be quite honest I immediately thought to myself... "bye bye dotLRN... would have been nice", yet we obviously had to take a much closer look before we could make any major decisions. So I invested time into getting a general overview of what .NET is about and then I tried to talk to people involved with the iCampus project.
After doing superficial research on .NET we have come to the preliminary conclusion that much of the Microsoft philosophy for Web development is focused on server-side controls (which makes it clear why .NET is so appealing to a company that sells server software and is looking for innovative ways to maintain its present income). What about Mono... the "Open Source" Unix version of .NET? Staying days, weeks, or even months behind .NET eventually wasting major time on reverse engineering unpublished features of the .NET framework does not sound like a wise decision (not to mention possible performance problems... which reminds me of the extreme fatigue that can be associated with infectious Mononucleosis). There are also rumors in the Mono realm that there may be legal protection in place that leave a (intentionally or unintentionally) "kill Mono" option open (wether it is acted upon or not). Finally how MS has treated web standards in the past, does not exactly build faith that they will respect standards in the future.
Our initial conclusion in Heidelberg is that it would be a MISTAKE to introduce dependencies on .NET into dotLRN (not to mention the fact that our main partner in this endeavor, the University Computer Center, is very resistant to having Microsoft products running as servers for security, business, support, and other reasons). We also feel that a rewrite of existing dotLRN functionality using .NET would be a waste of resources that could be used more wisely.
Next step... what is iCampus http://www.swiss.ai.mit.edu/projects/icampus/? "A research alliance between MIT and Microsoft enhance university education through information technology [...] sponsoring innovative projects with significant, sustainable impact at MIT and elsewhere." (from the website). This does not sound too incompatible with dotLRN. So who do we talk with? To start with it seemed that the best person to talk with was Dave Mitchell at MIT from Microsoft Research who manages the MIT/Microsoft iCampus alliance. He gave me a feeling for what iCampus is and what the motivation behind the project is. Afterwards I asked some questions about dotLRN. It became clear to me that it was still very early (he could not give me any specific information on funding) and he did not yet know that much about dotLRN.
I then looked iCampus projects from the past and present to see which might be interesting for dotLRN. I focused on the iCampus framework, because it seems like an iCampus project that could coexist nicely with dotLRN. http://www.swiss.ai.mit.edu/projects/icampus/projects/framework.html The focus of the project is to "illustrate the benefits of service architectures for university educational computing infrastructure". This specific project is going to be using Microsoft's .NET architecture to implement certain services, but for dotLRN what makes this framework interesting is that it will interoperate with Web service architectures that adhere to the World Wide Web Consortium's service standards based on SOAP (Simple Object Access Protocol) and WSDL (Web Service Definition Language). dotLRN being able to talk using SOAP and WSDL, would obviously be a very good thing (as Roberto mentions above). It is obvious that we need strong support of web services standards in OpenACS and dotLRN.
Our conclusion in Heidelberg: using the iCampus funding to get dotLRN to talk with web services enabled applications would be GOOD... introducing dependencies on Microsoft software or services or putting energy into creating a new version based on .NET tools would be BAD. dotLRN is based on OpenACS and like OpenACS it should remain OPEN. It does not look like the goals of the iCampus project necessitate the use of .NET.
Why do we feel that we can take the risk of going with dotLRN without knowing if there is going to be Microsoft funding and what it will be for? First of all MIT-Sloan gave us the feeling that they are interested in having the users of dotLRN have a very active role in the dotLRN decision making process. OF also gave us the feeling that, regardless of what happens, there will be a version of dotLRN that they and other vendors will support regardless of decisions MIT-Sloan makes in one to two years from now. The main reason that we are willing to take this risk is because we believe that the system fits our users needs much better than other systems, dotLRN is a system being actively used, with a very high acceptance, and most importantly we feel that the momentum that is building behind dotLRN (from very diverse sources) will make dotLRN based on OpenACS a sound platform, easily able to deal with this and other kinds of funding in the future.
Okay.... this is the more objective Carl from the dotLRN EB speaking:
When and if these funds come into play for dotLRN I want the TAB and gatekeeper to step in (because this is to a large extent a technical decision). I am confident that the strong OpenACS representation that is crystallizing in the technical leadership of dotLRN (Ben, Don, Dan, Lars, and ....) would make the best decision for both dotLRN and OpenACS inevitable.
Do not be mistaken, I will voice my concerns, my opinions, and my arguments in such matters, yet I must act on what the TAB recommends. I see the position that Al has given to me as a lever outside of the MIT sphere... one that keeps the interests of the greater dotLRN and OpenACS communities up front until a stable consortium forms. I also see my role in making sure that the TAB recommendation is heard and does not interfere with the interests and concerns of the users of dotLRN (represented through the UAB).
<p>
Because some aspects of the proposal are confidential, I do not feel comfortable discussing everything in a public forum. I will establish a private forum in SloanSpace for continuing this discussion. I encourage anyone in the OpenACS community who is interested in participating to contact me. I will make sure that you obtain access to the private forum. I look forward to your feedback.
I couldn't agree with you more on all the points you brought up.
Is dotLRN different than other organizations that have cooperated with Microsoft? How, how not?
Over the twenty odd years that Microsoft has been in business, are there any examples of ventures that are similar to the venture dotLRN is pursuing with Microsoft? Are all of these outcomes acceptable to dotLRN within the risks of probable outcomes?
Should Microsoft make any intellectual property claim on any dotLRN code etc, does dotLRN have the resources to provide a competent legal standing in the face of an adversary with essentially unlimited resources? What do historical records involving legal disputes with Microsoft record?
(Al and anyone else considering this as a future option) Does resigning from an influential position benefit or hamper the struggle to retain principles and goals, when in the presence of opposing forces?
How should someone responsible for making decisions about the future of dotLRN be held accountable for the impact of a venture with Microsoft in "icampus"?
What might be the impact of significant programming resources (and the fruits of their work) currently available for the dotLRN project being redirected to "icampus"? Might the discussion on dotLRN governance, and its impact on dotLRN development, indicate a significant disruptive potential (risk) of venturing with Microsoft in this opensource environment?
How can an opensource community retain an equitable relationship with a party (Microsoft), when the community is not provided full-disclosure of the terms of the working relationship?
With all sincerity for positive outcomes,
Your concertns are entirely understandable. However, it's important for everybody to be clear on just where we are. There is no deal with Microsoft. Money is being offered by iCampus, an MIT project that is funded by Microsoft. Al and Carl are evaluating the offer with a skeptical eye. They have made their criteria for acceptance of any grant money very clear in their posts above. They have also made it clear that they are perfectly willing to reject the money if there are unacceptable strings attached. Al has invited all interested community members into a semi-private discussion of the terms of the potential arrangement and, presumably, whether and how the money can be accepted without compromising the goals and values of the community.
For such an important topic, it is critical that we all understand exactly where the situation is right now. Philip G's post regarding the situation was false (though I'm sure there were no ill intentions on his part). The rumor he inadvertantly started was based on just enough truth to get people understandably upset. We need to be especially careful not to add to the misunderstanding.
That said, I do think there are some things which dotLRN could benefit from: becoming "web services enabled", and running properly on Windows are both on that list. The former would be relatively easy to do today, but the latter is not. AOLserver is no longer supported on Windows, so at the very least, a solid Windows version of dotLRN needs to either support it's own version of AOLserver, or work with Apache. Neither of these are trivial undertakings and IMHO it would be appropriate to use Microsoft's money to achieve them, as long as the proper precautions are taken. So these are some good things which might possibly come out of the iCampus grant. (ok, one might question why running on Windows matters, but folks like Michael have made it clear that they have clients who won't use dotLRN unless it does, even though the thought makes most of us cringe)
None of us knows yet whether an actual port of dotLRN to .NET will happen, since no decisions have been made. But it is clearly the most "scary" scenario here, and as such I think it is worth discussing. If it happens, there are a few possible outcomes:
- the .NET version runs with Mono and kicks butt, subsequently taking over the world
- the .NET version runs with Mono and is slow; only MS shops with pointy-haired bosses want to use it
- the .NET version runs with Mono initially, but MS pulls some kind of licensing trick and forces everyone with Mono apps to run them with licensed .NET tools instead; in that case, only MS shops who don't care about this will use it
I think the main thing to keep in mind here is that Al's primary goal is to see dotLRN be adopted as widely as possible. He's not going to achieve that if Microsoft is perceived as owning the project, or if performance is poor, or if the community around dotLRN is divided into two warring groups. So you don't have to believe that he has the community's best interests at heart in order to trust him - his own self interest also dictates that this process be handled carefully and that the outcome is something that the existing community can accept.
Let me tell you in BIG CAPS, IT AIN'T GONNA HAPPEN. Microsoft won't allow what it considers viral licensing into any project they fund. They may port it completly to .NET, but make no mistake about it, it will run on SQLserver and IIS with C#.
As far as misleading, yes dotLRN probably won't be funded by MS, but I have heard other rumors to the effect that there are already two people working on a C#/.NET version right now. I don't know if these two are MIT funded, but certainly one or more of them work at MIT (and no it isn't Phillip).
All those rumors could be false (including Phillips) but I seriously doubt it. MS needs to get at higher education and this is an easy fruit to pick; steal the data model (which may or may not be covered by the GPL) and build on it. This also has the added benefit of MS being able to upsell all the Universities who got "sucked in" to this virally licensed .LRN.
I have no doubt that the people currently working on .LRN (either technically or otherwise) have the best intentions, but when your boss (MIT) gets into bed with MS and they have a revelation, after a nice big donation, that all eLearning needs to be using the latest and greatest MS offering, we will see who wins (principal or money).
Will this happen? I certainly don't know, but I think it is a likely scenario if the rumors are true.
Yours ever controversially.
Let me tell you in BIG CAPS, IT AIN'T GONNA HAPPEN. Microsoft won't allow what it considers viral licensing into any project they fund.If this were unequivocably true, then talks between MS and MIT would most likely have ended already. I'm not privy to details but my understanding is that 1) MIT and MS have been talking 2) MIT has made its intentions clear 2) MS is still talking
I doubt that MIT's legal team have forgotten the Kereberos fiasco. MS didn't fund it, they just took advatage of the BSD-like MIT license , took it, and changed it to the point where Kereberos won't work with MIT's verison Setting themselves up to be ripped off again might happen, but I'm not terribly surprised to hear Al state it won't happen.
As far as misleading, yes dotLRN probably won't be funded by MS, but I have heard other rumors to the effect that there are already two people working on a C#/.NET version right now. I don't know if these two are MIT funded, but certainly one or more of them work at MIT (and no it isn't Phillip).
Al has stated that Philip's post is incorrect. Who to believe? It's possible that Al's misinformed, I suppose, but I doubt it.
All those rumors could be false (including Phillips) but I seriously doubt it.
Why? Al says they're in the study phase, no reason to doubt that. He says no deal's been closed, nor is there physical work being done. I see no reason to doubt that, either.
Answer this: if MS has already awarded this large grant to MIT, how come it's not been in the press? MS is going to milk this for all it is worth, and so is MIT. I'd bet money on a joint press release and I'd bet money on the NYT picking it up in the business section.
MS needs to get at higher education and this is an easy fruit to pick; steal the data model (which may or may not be covered by the GPL) and build on it.The datamodel, expressed in SQL, is covered by the GPL just like any code. They can re-engineer it, of course, just as they could Linux or gcc.
If the datamodel weren't covered by the GPL, they wouldn't have to give MIT a large grant in order to rip it off. They could just do what MS has done in the past with Kereberos and the BSD TCP/IP stack ... use it legally without paying anyone a penny.
Since when has MS gotten so generous that they'll pony up large sums of money for something they can get for free?
Conversely, if the datamodel is covered by the GPL then that extends to the OpenACS datamodel. Remember that dotLRN is built on a bunch of standard OpenACS packages and their datamodels. MIT doesn't own copyright to those things and can't, for instance, agree to MS's having the right to issue those pieces in a proprietary way.
Now ... Torben's "deep pockets" comment about the success of a lawsuit if MS were to ignore the GPL and just rip off pieces for their own use is certainly one to think about.
But again ... they don't have to give MIT money in order to rip folks off. If they decide to rip off this or any other GPL'd project based on thinking that they can beat any legal suit, they'll just do it.
This also has the added benefit of MS being able to upsell all the Universities who got "sucked in" to this virally licensed .LRN.There is this risk, yes.
I have no doubt that the people currently working on .LRN (either technically or otherwise) have the best intentions, but when your boss (MIT) gets into bed with MS and they have a revelation, after a nice big donation, that all eLearning needs to be using the latest and greatest MS offering, we will see who wins (principal or money).Which I see as another compelling argument for getting the dotLRN Consortium up and for getting the dotLRN copyright assigned to the Consortium.
Because the Consortium will not be MIT, it will be its own legal entity. Imagine that MIT gets funded and then screwed by MS, despite its best legal efforts to ensure that they get the former without suffering the latter.
This doesn't impace the Consortium nor does it impact us.
Will this happen? I certainly don't know, but I think it is a likely scenario if the rumors are true.The fears are rational, no doubt about that. I'm not downplaying them. But from our project's POV (OpenACS) and the dotLRN project's POV I see nothing to fear. Dilution of resource is one possible fear, but then again MIT is talking about adding MS money to the pot (or more accurately it's not the same pot). And whatever shakes down, we're seeing more resource made available to OpenACS/dotLRN in the near term and that's not tainted with MS money, not at all.
So IMO the absolutely worst thing that can happen from this is that the OpenACS community finds itself where it was a year ago except of course we'll have this great vertical app called dotLRN available unde the GPL, we'll have had a bunch more pieces added to it, we'll undoubtably have things like dotWRK out there ...
I mean ... MicroSoft's trying to take over the world with .NET and lock us all into a non-Open Source world, there's no doubt about that. Worst case from MS/MIT cooperation is that MIT might end up aiding and abetting MS's desire to do this, despite doing their best to push some .NET/Mono technology out into the world under the GPL.
But in all seriousness ... the practical effect of any accidental aiding and abetting is pretty much small potatoes. I worry more about MS's efforts to push Palladium, digital rights management, and similar things as being efforts to cut the heart out of the Open Source world.
Anything they do in regard to MIT would at worse mean that at some point in the future MIT funding of OpenACS-based work disappears in favor of funding of the .NET platform. That doesn't mean that we all of a sudden have no toolkit. Nor does it mean the Consortium disappears over night. All it means is a loss of a funding source for OpenACS-based work that didn't even exist 15 months ago ... we were surviving then, we'd survive this, too.
In the short term ... it's pretty clear that a near-term need will be integration with SOAP and the like. Things that many folks have said they need and want. This kind of stuff needs to happen with or without MS's grant to MIT and if anything is going to get funded by Sloan/MIT or other institutions or other clients not remotely related to the dotLRN world, it's going to include this, I'm quite sure.
I thought that I read discussions to the effect that data-models are information and therefore exempt from copyright(left). Take for example, a schema person with firstname,lastname. If that data model is copyrightable then I will be first in line to file.
An analogy in the music business (which I am fully versed in copyright). You can't copyright titles and you can't copyright chord progressions. I think this would apply to this domain as well. If you can copyright data models we are all in violation as I am sure that someone did (amazon, MS,Sun).
Now the process of using those tables may be patentable, but I am not sure how copyright would work in the straight data model scenario. I am sure I can reverse engineer the data model of ACT and make my own with a different front end and they couldn't do anything about it. The same goes with Quicken and a lot of other programs.
<p>
If we proceed with iCampus, then it will be as a *research* project to understand how a platform like dotLRN might be constructed from the ground up using a componentized web services architecture.
<p>
We would have three general aims:
<ul>
<li>understand how enterprise services (authentication) could be delegated, preferably using OKI (Open Knowledge Initiative) APIs;
<li>understand how certain modules might be delegated (e.g. calendar, file storage) to external systems or applications;
<li>understand how the platform could be constructed so as allow consumption of web service data and applications, especially in learning management space;
</ul>
The funding that we are likely to receive is a fraction of what we would need to do full .NET port. The decision to do a full .NET port would come a year from now, depending on lessons learned, whether there's funding available, the state of Mono, and an overall careful analysis. It's way too premature to say that we are undertaking a .NET port.
<ul>
<li>
Can we achieve the same research goals by focusing exclusively on OpenACS? Yes.
<li>Will Microsoft fund it? No.
<li>Might we be able to use some of the iCampus money to further the dotLRN/OpenACS project? Possibly.
For example, I would like to modularize the calendar functionality in the current version so that we have the option to store events in Exchange using Calendar APIs.
<li> Will Microsoft get a seat on the dotLRN board because of iCampus? No.
<li>Are there people at MIT working on dotLRN/.NET? No. Tracy Adams and Andrew Grumet, who work for me, have been learning .NET and would participate in the project if we move forward.
</ul>
What I urge you to think about is the following: if we can obtain funding and resources from Microsoft to strengthen dotLRN but using .NET in some way. Should we accept? If so, how should the funding and resources be used?
What I urge you to think about is the following: if we can obtain funding and resources from Microsoft to strengthen dotLRN but using .NET in some way. Should we accept? If so, how should the funding and resources be used?
This is an excellent way of framing the issue, Al. Like many, I am very uncomfortable with the thought of a C# port. However, there are some things that I would like to see:
- Integration with .NET applications would be great, provided that (a) the integration is optional and not part of the core dotLRN stack, and (b) the integration can be done with purely Open, non-Microsoft code. Integration with Outlook/Exchange is one great idea. I'd also love to see dotLRN interoperate with Groove, and I wouldn't mind seeing it interoperate with Blackboard Transaction Server. As I see it, if we stick with SOAP and other standards, we can integrate with Java, or whatever, just as easily. The .NET stuff would just be a first test of the concept.
- I also wouldn't mind seeing dotLRN running on Windows servers. Again, I wouldn't want this to be a requirement [shudder]; just an option for those who want it.
- As a hedge, it wouldn't be a bad thing to see some kind of nsmono like there's an nsjava (except have it actually work). I wouldn't want to see the dotLRN code depend on it, but having it there would eliminate one more argument against adoption for those who need to run .NET.
- Finally, SQL Server compatibility wouldn't be a bad thing.
All of these suggestions have some common characteristics. First, they bring .NET to dotLRN/OpenACS rather than the other way around. Second, they make sure that .NET is not required to run dotLRN. Third, they increase user choices.
I'm kind of surprised at your statement that nsjava doesn't work. What is your basis for making this statement? Have you downloaded it lately and tried it? Is it missing features that you think are essential for it to be considered working?
At any rate, my comment regarding nsjava is based on old information which was hearsay at the time.
Now the process of using those tables may be patentable, but I am not sure how copyright would work in the straight data model scenario. I am sure I can reverse engineer the data model of ACT and make my own with a different front end and they couldn't do anything about it. The same goes with Quicken and a lot of other programs.You can reverse engineer Virtual C++, too. You'd just better make sure it doesn't look like a stolen copy of the source code to Virtual C++ ...
We may be talking slightly at cross purposes here in that the data model's a bit like (say) Linux. Just as surely as Oracle can run on top of an installed copy of Linux and remain closed, MS could run something on top an installed copy of our data model.
But the source to our data model is covered by copyright and released under the GPL just as is the source to Linux. Just because it's written in SQL rather than C doesn't make it non-licensable.
So I suspect you may be thinking about whether or not you can run on top of the data model once it's installed?
Can one reverse engineer the data model by just having Oracle spit it out and reconstruct it using different names, etc? That's a toughie ... certainly you can decompile the datamodel much more completely in this way than you can decompile a running binary so the level of practical vulnerability is a lot higher than for a traditionally compiled C program.
But then again obsfucating the source in the first place is easy to do for either C or SQL code and this way of trying to circumvent the GPL has yet to be tested in court.
And I still agree with Torben's assessment that if MS tries to work around the GPL with the presumption that they'll win in court due to superior resources, there's really nothing one can do.
But if the won such an action it would undermine their "GPL is viral, stop the GPL" political fight against Open Source, too ...
Michael and Dan .. I think the flakiness had to do with JVM issues. Didn't the IBM JVM crash at some point while the Sun one worked, or vice-versa, due to some issues with running in a threaded environment?
That's how I remember the flakiness, it wasn't with ns_java per se but with one or more JVM releases available at the time.
Now Dan's going to tell me that if I weren't lazy and RTFM'd over at his nsjava sourceforge project I wouldn't need to suggest posting any status information in our forums :)
I want to clarify what I think I understand about copyright.
The exact source code to OpenACS is definitly copyrighted just like any code. The actual tables aren't.
What I mean by that is that if I take a copy of OpenACS and create my tables then I have to abide by GPL. However, if I read documentation, or simply do a dump of another system (like you suggested), I think the courts will say that this is information as opposed to intellectual property and that is the key difference. I could also keep the table names the same (names can't be copyrighted) and rebuild the plpgsql (which would have to be done anyway in whatever sqlserver uses). The only compatibility really needs to be with the actual tables and the rest can be clean roomed very easily. I certainly wasn't suggesting that they would just steal our code. All they need are the tables.
Of course as you say, it is all really academic in the fact that MS has already proven it can do what it wants, and if 5 years from now there is a remedy so what, they will already own the market.
Now, where does this leave dotLRN? Take into account that universities might not like the complete package but are keen on using a special BBoard or a cosy News and CMS package. What dotLRN should provide is the possibility to use these services instead, using well defined (by the TAB) interfaces. Furthermore, go the other way round as well, open up the modules to be queried by other websites/services. If a student does like to keep his calendar in Yahoo, allow Yahoo access to the dotLRN calendar. If they want to use fastmail, provide them access to the mail stored in the database.
Therefore, as my consecutive question, will the dotLRN movement consider opening up the architecture to allow webservices in both directions and is this something already on the list of desired features of the stakeholders especially in the EB {as this would most likely get funding first}.
That question has already been answered in part by Al, so no need to restate unless you see it even further 😊.
Therefore, as my consecutive question, will the dotLRN movement consider opening up the architecture to allow webservices in both directions and is this something already on the list of desired features of the stakeholders especially in the EB {as this would most likely get funding first}.Well ... more importantly the OpenACS community seems to recognize the need for two-way services of this sort.
Look at the fact that we've already got an RSS package that lets you dump content to any other server that understands RSS, and look at the interest that's been expressed about SOAP (which by nature implies an interest in two-way behavior). Look at the interest shown already for IMAP support for any webmail type package we might want to have, and calendaring support (there's been a lot of interest even in that little hack I did that's in ACS 3.5).
So fundamentally I don't think there's any selling to do to our community here.
There's just a ton of work involved ...
Of course if I'm wrong I'm sure people will point it out, but over the last year or so there's been a *lot* of discussion about wanting to be able to integrate with XML-based exchange protocols like SOAP and RSS.
All we need to make OpenACS/dotLRN services be available via ".NET" is to have XML (already have that one), SOAP (Tcl has that), WSDL and UDDI (I'd assume Tcl SOAP has those two as well).
I've been wanting to write a small proof-of-concept OpenACS package using tDOM that would make some OpenACS service available and also make use of the google SOAP API (http://www.google.com/apis/)
The googleapi demo also includes a .net example and a perl example.
That great though. I'm glad that you posted that nsjava status document, as it no doubt will be very useful to OpenACS in situations where hooking up with Java are necessary.
I'll play around with tDOM to see if I can get it to search google. That way we can compare notes and how we went about doing it.
The reason I'm more interested in the Tcl SOAP stuff is because tDOM seems that can completely replace nsxml (which is no longer actively maintained, where tDOM is), and there are reports of good performance improvements over nsxml.
Perhaps we'll have to keep a compatibility layer with nsxml calls though.
Of course folks using nsxml privately can continue to do so.
package require nsjava
# import the google search classes
nsjava::import -package com.google.soap.search GoogleSearch GoogleSearchResult
set result ""
# create a google search instance
set s [nsjava::new GoogleSearch]
# set the authorization key
$s {setKey String} 0XmNi33L1CMmAUFQxxxbOyyyDzdf
nsjava::try {
$s {setQueryString String} $q
set r [$s doSearch]
} catch {GoogleSearchFault f} {
append result " The call to the Google Web APIs failed:[$f toString]"
}
# was a result returned?
if [string equal $result ""] {
set count [$r getEstimatedTotalResultsCount]
set etime [$r getSearchTime]
set sidx [$r getStartIndex]
set eidx [$r getEndIndex]
set els [$r getResultElements]
set result "<h3>Search Results ([expr $eidx - $sidx + 1]) item(s) in $etime seconds</h3>
"
set cnt 1
for {set i $sidx} {$i < $eidx} {incr i} {
set el [$els get $i]
append result "${cnt}. <a href="[$el getURL]">[$el getTitle]</a><br>
[$el getSnippet]<br>"
incr cnt
}
}
ns_return 200 text/html $result
It turns out that the googleapi.jar file contains the following contents:
- com.google.soap.search.*; Google's own Java wrapper for the API SOAP calls
- JAF 1.0.1 (activation.jar) http://java.sun.com/products/javabeans/glasgow/jaf.html
- Javamail API (mailapi.jar) http://java.sun.com/products/javamail/
- Apache SOAP 2.2 (apache-soap-22.jar) http://xml.apache.org/soap/
- Apache Crimson 1.1.3 (crimson.jar) http://xml.apache.org/crimson/
So other than the google soap wrapper api, the rest of this code is freely available. Assuming that nsjava could be made to operate reliably (including easy installation), soap integration with aolserver is already freely available now.
