----- Original Message ----- From: "Costin Manolache" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, January 06, 2004 11:06 PM Subject: Re: Jk2 object model
> Mladen Turk wrote: > > > > > > From Costin Manolache > > > >>Sent: 6. siječanj 2004 8:11 > >>To: [EMAIL PROTECTED] > >>Subject: Re: Jk2 object model > >> > >>jean-frederic clere wrote: > >> > >>>Costin Manolache wrote: > >>> > >>> > >>>>I remember some time ago Mladen (?) was suggesting to use > >> > >>C++ for jk2 > >> > >>>>instead of the pseudo-OO programming. > >>> > >>> > >>>I am -1 for using C++... And wondering why you want to use C++. > >> > >>I don't actually want to use C++ - I'm just a bit unhappy > >>with the "reinventing the wheel" object model in jk2, and I > >>was wondering if any alternatives have been discussed. > >> > > > > > > Me too... > > The JK2 IMO is a pretty dead project. > > Henri tried to boost that forcing the APR as a default, we did some work, > > but it is agin stalled. > > > > IMO for the majority of the people the JK is sufficient enough. > > Using APR in JK would perhaps make it the same as JK2. > > There are few big differences in JNI handling - the in-process for jk1 > is even slower than out-of-process, and didn't work with tc4. > There is also a lot of "jmx-like" management and monitoring that I think > is quite usefull. > > But you are right - jk / jk2 is probably good enough, no major itch to > triger big changes. That's not necesarily bad. > > > > > As I see it, most of the people are looking at JK2 as an enhancement over > > the JK, but in the real life there is not much technological difference. > > We still have a same packet communication between them (that hasn't changed > > conceptually from jserv). > > > Well, it hasn't changed since RPC :-) You have 2 programs communicating, > there aren't too many ways to do it. What's important is we figured > that in-process with JNI is faster using packet communication. SWT > figured it's faster using ints and byte[] - which is the other solution > to avoid the really bad performance of jni ( and strings ). > > I'm interested if jk2 could "plug" into more applications - there aren't > that many generic "connectors". KDE has one specialized for konqueror, > and mozilla has one - both are mostly for applet support, with xconnect > hardly used ( and I heard pretty slow ). If jk2 would support (XP)COM or > gtk object model - it may be possible to access and control various > desktop application with some simple web-like requests. > The big problem that I see is that currently jk2 uses 'abstract classes' to enable it to handle the fact that that the 'implementing class' needs to control I/O (reading the Request, writing the Response). This doesn't fit well with other frameworks. IMHO, this part would need to be re-writen to work on something more like a Listener model (certainly required for a COM implementation :). However, this may mean a performance hit when using the standard Apache/IIS/SunOne modules. > > > What I would like to see is something different in approach to the problem > > of integration. > > > > > >>So I was wondering if jk2 or > >>something similar could be used as a connector into apps like > >>mozilla or evolution ( or any other desktop app ) and allow > >>access to the services and info inside. > >> > > > > > > Something simmilar I woud say :-). > > Starting from scratch is allways a bad idea ( IMO ). > > Costin > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
