We also have a large JC app, and I agree with everything Robert says.
It looks like we have about two years to get off JC. It works really
well, up to a point. I think the Apple parts work well, and the Swing
parts not so well – table cells being a case in point.
Maybe there was a time when three-tier client-server was the great
white hope. But come to think of it 3tcs has never really worked
well. Burroughs introduced the MT terminal in the early 80s which
split off the user interface into the terminal with validation code
and everything, but that never seemed to quite work. Apart from the
hardware was horrible compared to the TD830 (M6800-based terminal),
and the later ETs and B20s (8086-based modular network PCs), I think
application programmers were just happy to have all the code on the
server (where you still had to do validation anyway).
JC did seem to offer a better approach to 3tcs. Maybe if it worked
flawlessly, it might be great, and I suspect that to get it to work
as well as it does requires a lot of code in WO, which Apple doesn't
have the resources to maintain.
So, as ever, it seems that the approach that works is to generate a
user interface on the server (now done in WOComponents and HTML) and
do all the validation, etc on the server. OK, it might mean more
network round trips, a little bit more processing on the server, but
if response times are reasonable, that's acceptable. Whoever said the
mainframe was dead was being somewhat premature – servers are today's
mainframes ('server' is just the politically correct way of saying
'mainframe').
I'd say the weak link in all this is HTML, which has been dummied up
with technologies like JavaScript and AJAX (to get some processing
back in the browser), and that's why people have done JC to give a
more professional desktop experience – only it doesn't quite deliver
on that promise (probably because Java does not deliver on that
promise). HTML requires a lot of bandwidth, which we now have (it
would not have worked years ago on a 9600 baud or slower line).
Seeing HTML and JavaScript are inherently weak technologies (while
they work OK for web browsing), perhaps there is room for a future
protocol where you can do professional desktop interfaces, where each
page is dynamically generated, like WOComponents on the server (so
it's not 3tcs). I doubt that a standards body (like ISO ODP, hmm some
interesting stuff there under Google) could do this. (A UI
description language, rather than a programming language.)
Anyway, I think that is a long way of agreeing with Robert, that JC
is a technology that is past its prime, but people will still lobby
for it, because ultimately the web browser HTML/AJAX experience is
unsatisfying.
Ian
On 27/06/2007, at 5:33 AM, Robert Walker wrote:
First, as I told in a precedent msg, it's important that Apple
knows that JC is used and by whom. Maybe we can hope to get the
source code of JC palettes to rewritte them for IB v3...
It's not likely that we'll ever have access to the source code for
JC (snowballs and hell come to mind). Even if we had the code, I
just don't see any practical way to use that code without the Cocoa-
Java Bridge. So IB 3.0 is out, whatever the case, unless someone
wants to create some new Cocoa-to-Java bridge technology. I'm
certainly not volunteering for that.
I saw the signs of JC's possible demise at least three years ago.
When Apple (or any vendor) begins putting "hints" in the
documentation that you should start to think about moving away from
some technology, we should really listen. Yet, all we seem to do
is complain that they have finally done what they said they were
going to do.
My fear is that if a commitment is made to keep JC alive, that
might limit resources that have been committed to making WO the
best server-side technology that it can possibly be. It could also
hinder efforts on making IB 3.0 the best that it can possibly be
for building Cocoa user interfaces. Neither of which are good for
Apple nor for us.
I think Chuck had a very good point about alternatives. It seems
to me like it's time to find a better way to do client-side
applications than to build more JC applications. If we want Swing
user interfaces, IB is NOT the way to do it IMHO.
In case some are wondering, I do have several JC applications that
I maintain. But, I'd still be glad to see it go. It has some
interesting features, but I've found it so annoying to work with
that I have to say: "JC rest in peace, you will not be missed. At
least not by me." My future plans for maintaining JC apps is to
keep a machine around running Tiger, WO 5.3.3/JavaSE 5.0 just long
enough to get my applications ported to some other alternative.
Who knows, but I'm betting someone comes up with something really
great. There are lots of really smart people on this list, and I
look forward to seeing what they come up with.
On Jun 26, 2007, at 11:02 AM, Philippe Rabier wrote:
On 26 juin 07, at 15:30, [EMAIL PROTECTED]
wrote:
Since you and a few more people are interested, I will make it. At
the moment I am too busy to put much time into it, but that should
change in a week or two.
Cool
I have two questions still:
1. How and where to most effectively lobby for JC future with Apple,
or at least for an answer??? There seems to be enough interest
for it
for some of us to work together in documenting this and exchanging
info, techniques and code, but we NEED TO KNOW (hint to Apple
people)
is there any point in it ?
First, as I told in a precedent msg, it's important that Apple
knows that JC is used and by whom. Maybe we can hope to get the
source code of JC palettes to rewritte them for IB v3...
With the different mails, I have now a small list of people
involved by JC. I don't know yet how we can organise ourself
(maybe a dedicated mailing list ?)
2. To all WO users, not only JC, shall we make this effort a part of
some big WO site? I must admit I am not sure what sort of consensus
was reached on centralizing resources. Or do we start another
standalone thing? If not, with whom should we coordinate this?
We discussed about that during last WWDC. One developper from
Google told us that it's not easy for a newbie to begin with WO
because there is not a single place where you can find everithing
to begin. From my perspective (and not only mine), the good place
is to put more information in the wiki book (http://
en.wikibooks.org/wiki/Programming:WebObjects).
That's the reason why David LeBer has initiated a "WO get started"
web site with links to different websites like the wiki book.
Some of us could be surprised by this discussion about JC. I agree
with Chuck that it's not a good idea to begin a new project with
JC but the projects, I know, are very big so the lack of support
in a "maintenance mode" is a big problem. And maybe we could
create a dynamic to invert the processus (requires a lots of
works ;-)) if we are able to show how we can use effectively JC.
Philippe
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/
robertwalker1%40mac.com
This email sent to [EMAIL PROTECTED]
--
Robert Walker
[EMAIL PROTECTED]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/ian.joyner%
40sportstec.com
This email sent to [EMAIL PROTECTED]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
