Appajee, In an earlier email you said that you can use the 7.1 Java api to connect to a 7.01 server
"What that means is -- the client program runs the pure Java code in issuing AR API's underlying RPC calls when interacting with servers of version 7.0 or greater" Can the java plugin-server connects to a 7.01 server? Since the 7.1 java api fallback to old JNI when connecting to version 6.3 or earlier, would it be a good practice to use the 7.1 java api to write clients even when the server is an old version? I suspect the 7.api is more "Java" than the old one... -- Jarl On 8/14/07, Papolu, Appajee <[EMAIL PROTECTED]> wrote: > 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" > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
