Axton, While I cannot give you a pretty concrete statement about this, the general thinking is as follows:
Yes, plug-ins can be developed using the first class SDKs - C or Java. Thus the plug-ins existing or newly developed with either language will be supported. While the above holds true for the plug-ins themselves, the plug-in server itself may be a different story though. Once we attain equal or better functionality/stability/performance goals, the plug-in server implementations in C and Java would simply be redundant -- thus I see the possibility of consolidating into only one plug-in server deliverable in future release(s). I am already seeing follow up questions on this comment, so here go few answers: 1. Did you not attain these goals yet? A. For most part yes, but not 100%. For example, we know that on Solaris - hosting C plug-ins in Java plug-in server, we ran into some stability issues especially if some other Java plug-in uses AR System native libraries (like Java API or CMDB API). In such environment, we encourage users to do side by side deployment of C plug-in server to host C plug-ins and Java plug-in server to host only Java plug-ins (& disable hosting any C plug-ins in it). Eventually we're hopeful that we'll resolve such limitations. 2. Any other issues? A. We would like to see the transition rate/ease for users from C Plug-in Server into the new Java plug-in server. Or, at least side-by-side deployment of both of them. Hopefully in 7.1 release we accomplish this smoothly. 3. Which plug-in server would stay (OR) which one will go? A. We implemented an all new implementation ground up now. So draw your conclusions. Any way, the eventual decision will greatly be helped by the readiness of users, rate of deployments of Java plug-in server and of course the elimination of rough edges in the Java plug-in server in all supported platforms. Your questions/comments/concerns/suggestions are welcome. Regards Appajee PS: Comments about future features/roadmap are just indicative of what our current thinking is; by no means it is set in stone and is pretty much subject to change depending on various factors. Another side note -- in future, I see the possibility of filter API plug-ins may indeed have SDK/mechanisms, so that they can indeed be created using other (Java hosting friendly languages) such as JRuby, Rhino/JavaScript, Jython and so on. As Filter API is the way to integrate 'scripted/custom logic' into AR app workflow, I believe opening it up for other languages is pretty powerful. (Lacking this, users with such needs will either give up or resort to cooking up their own plumbing code themselves.) -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Axton Sent: Monday, August 13, 2007 7:24 PM To: [email protected] Subject: Re: AR System 7.1.00 delayed until end of August / early September With the new java api/plugin server, does the roadmap include ongoing support for both c and java plugins? Axton _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
