Here's some hints....

1. I am comfortable in the prediction that Notes 8, built in the Eclipse framework, will be a truly valid Lotus Notes client in every respect -- in addition to so much more. It will be as valid a Notes client as... say... any new Notes client would be for a new operating system. Suppose "Uncle Ernie's Used Computers" started selling a brand new OS at their annual "Babbage's Birthday Bargain Bash" and for some reason it took off and within months had a 90% market share. The folks in Westford would need to build a Notes client for it. They way they would do that, is the way they're building a Notes client into the Eclipse framework.

2. If you learn to build plug-ins and SWT gui stuff for the Eclipse Framework, then if at some point in the undisclosed future the Notes 8 client were to actually come out built in Eclipse as they've said publically is their goal -- then you'd be able to put really cool UI stuff on traditional Notes applications, right? That kind of work is how ISV's and consultants make money -- building advanced stuff that's a step or two beyond the internal development skills of most corporate dev teams.

3. Notice that neither statement 1, nor statement 2 involved any discussion of Lotus Workplace as a back end.

4. Notice that neither statements 1, 2, or 3 disclosed any new information that hasn't been said before by IBM -- its just been obscure, hard to find, and hard to understand or believe.

;-)

What confuses me about this whole deal is the concept of a rich client to begin with.

Seems like most people are saying, "Forget rich clients. Use the browser." And trying to make HTML/XML/XSL/web services, etc. do more.

This is not news -- this has been the direction most places I have worked since about 97-98.

IBM also followed this, with all the emphasis on WebSphere, Portal, etc.

Is the proposed rich client, then, an extended browser? If not, I don't see the excitement. Although feel free to enlighten me. :)

Dave,

The rich client isn't new at all in concept. Also, you're right to some extent in that additions to the generic web browser to make it more useable as a UI for real applications are not new either.

Up to this point, there have been two choices. You build a UI that uses only web browser technologies and get the relatively ubiquitious client at the desktop for less apparent cost/effort -- but you get a crappy place to do real application work and a poor security and user interface model -- or you build your own client as in classic client-server computing. Notes is one such client like that. The advantage is you get this full blown programmable user interface, where you know what's going to happen at the client side and server side, its secure, predictable, and good place to work (assuming you like notes). The downside is, its Notes only, big, and expensive to manage at the desktop compared to the browser. On top of that, you have to build the whole thing for each different os it will run on. That's very expensive -- and its why there's no current Mac Notes 7 (though its been finally promised -- just late).

The new rich client tries to solve both issues at once. They are trying take care of all these issues. Start witha frame work that's multi-platform already. Now, build a notes client to that frame work as if it were the os, and you've got a write-once run (almost) anywhere client. Since the frame work is extensible, you leverage it for all the other things that need a rich, secure, controllable user interface. Oh, and that extensibility leaves lots of room for us as programmers to make money writing cool add-ons for.

Bottom line, the Rich Client will take nothing away from what we're doing, but it will add many more additional places for us to add value.

i've seen quite a bit of talk lately, sometimes in some of the newsletters i get, and on some of the tech news sites, and chatter on some of the blogs too (i'm thinking of at least one thread on rocky's site in particular) that the paradigm in thinking is swinging back toward rich clients. in fact rocky probably never really left off thinking about rich clients as fundamentally Good Things, where so many of us had decided it was all about the web. the thought was, rich clients are clunky and hard to maintain, lets get rid of them! like andrew says, the browser is already deployed, its pretty lightweight, etc.

so i've been trying to understand why the trend is moving back toward rich clients.

one thought i had about it goes like this... what if microsoft had built their browser so well that you really could write fully functioning secure applications that worked like you really want them to, and what if you could do it all with DHTML?

lots of companies have built software around DHTML, sometimes trying to sell it as commercial software, but none of that stuff really went too far from what i can tell. google has delivered a lot to the browser as has yahoo and so forth, but their thing is about huge server farms that serve up very simple applications. those apps aren't exactly "rich". there are limitations the farther you go that direction.

if M$ HAD gone and made DHTML as powerful as a lot of people were sort of wishing / hoping that it was, what would stop someone from writing excel in the browser? or word or anything else? they can only go so far before they choke off their own revenue stream.

so really, i think the browser will pretty much stop at its original paradigm, which is the hyperlink. everything after that is bells and whistles mostly. probably the best rich client that is seen everywhere in the browser is flash, but then you run into usability problems simply because flash is flash, and the browser is the browser. people want flash apps to work like browsers, with back buttons and so forth.

anyway, all that to say i'm trying to get my head around it too. it sure is interesting.

thanks for participating in the thread andrew, way cool.

:-)

I've gone back and forth on the issue myself over the course of time. Back in the day, when Notes first rolled out internally at IBM, I remember a conference discussion with a bunch of other IBMers on this exact topic -- whether we should be developing Domino Apps, or Client apps. All the Admins in the room said 'Domino'. All the developers said 'Client'.

It seems like Admin folks still say to use the browser. Developers seem to have come around recently to also use the browser. I really don't see the difference in capabilities between client and browser as such a huge gap anymore. There is a gap, but it seems to be small enough to be workable for almost all applications.

I think the question on the browser end is more of a UI issue. To create effective web apps, you need the app architeched as such from day one. And doing so is a developing paradigm, so to speak. Most expereinced software architects learned to architect on rich clients. Most people who learned on the web are still fairly new.

So while I see the exceitement from a developer's perspective on a nice fancy schmancy rich client, when I take a step back and look at the overall architecture to deliver an app, I am not convinced that intelligent design, with a spattering of good solid web coding, cannot overcome the gap between the client and the browser.

I will be happy to watch as the technology developers over the next few years, and will be happy to be proven wrong. Anything that gives us more capabilities is good in my book.

What you've described in [4] is a good overall description of what Avalon and XAML are supposed to be. Declarative UI elements (in XML rather than HTML), a document object that can be addressed and manipulated by code, CSS to format the XML elements on-screen, etc. DXML, if you will. It's a big part of Longhorn, and what i've been able to see and play with in beta is pretty cool. XAML not only works on the Avalon desktop, it also works in the next generation of IE (which is why MS has stated that the next IE will not be available separately from the next OS -- the two are inextricably linked). MS "gets" the rich client, but they also recognize that the web browser alone ain't it. Unfortunately, getting there means committing to MS in a big way.

Sure Stan.

Microsoft wants the rich client, they want it to be theres and they want it to only run on Windows. Theyr'e still thinking in the 90's though, so they want to do with with things call xaml and such that they can call standards and that will kill them competitively unless they do what they've always done which is to "extend" the standard in their own engine -- which this time they won't build into the browser at all, so you can't sell a competitive browser with it for another OS.

The major issues with the browser, Dave, are maintaining state, screen refresh, and local sandbox control. Applets were the first attempt to correct this, but MS killed them effectively by mucking with jvm versioning and corba implementations. Java people did damage to themselves too, since ui coding in Java basically stunk back then. Also, you can't really extend a browser by definition. Its extensibility is not an inherent part of the browser specification.

What IBM is doing with eclipse, is making their rich client inherently extensible, and its that extensibility they're using themselves to build the specifics of the client into. In other words, they're not doing anything creating the notes client "plug in" that you couldn't do creating your own plug in (at least in theory - I must say I do not know this to be 100% true).

I think you need to stop thinking of the "browser" as anything other than "A" browser. Its a "WEB" browser. A better word would be a "Web Terminal". Its a terminal emulator. It doesn't emulate ANSI or 3270 or VT100 -- it emulates HTML or XTHML or Javascript or whatever.

The eclipse frameworks says you can emulate anything you want, here's a place to put your own emulator so it can talk with these other ones.

--AP

Wow, all very interesting and exciting. There's a nagging thought in the back of my mind though. Eclipse, as described here, comes across very much as today's version of Java (write once, run anywhere). So what's to stop MS (or anyone else for that matter) "extending" the standard ?

I hope it won't happen, but I've become cynical in my middle age :)

Great conversation guys - adds more concrete to my thoughts that IBM are on the right track and we have exciting times ahead.

They can't do it to eclipse, because the whole framework goes with the application that sits on it. They could make their own plug in that has windows services. The idea would be ifyou use their windows plug in you get some set of services that otherwise you have to build yourself (that's what they did with c++ for windows).

In this case, two things stand in their way:

1. Its no longer just about Macintosh or PC. The linux and mac communities combined represent a larger market share now than then -- and the whole point for many of the eclipse framework people IS its cross platform nature.

2. Most of the sevices they would provide already exist as programming objects. The SWT ui specification, the tcpip connectivity stuff, etc.... those services don't need extensions to work.

It really isn't the same environment. When windows was new and it competed against mac and os/2, c++ was still cross platform. MS said "yeah, but if you use our c++ libraries, you don't have to hand code all your windows gui stuff -- we'll do it for you, and you can hit 85% of your market 6 months faster." - a compelling arguement in those days that ended up locking out the other 15%. The environment isn't ripe for that today.

--Andrew

Andrew, I really, really hope you're right, and the growing market share of non-windows OS's and alternative browsers to IE is certainly encouraging. But there's a little cynical voice inside me that just won't go away. Hopefully it's just me being ultra cautious and the Notes 8 client will be the killer app that luanches Eclipse into the big time.

This is one development I'm going to follow with interest.

i think there is going to be an interesting battle ahead, and it will probably be all out war on a level we haven't seen before, esp if there ends up being real traction that cuts into M$ profits.

thank god ibm decided some years back to get into the software business in a big way. the competition is definitely pushing things in some interesting directions. i think if you are a M$ developer things are going to be better, and if you are a lotus / java / ibm / sun / mac / etc developer, things are going to get better.

in other words, i think the development community wins no matter what. more choices, more power, and lots of interesting things to think about, discover and play with. after all, its about toys in the end isn't it? if i can't have fun then i just don't want to play!

;-)

So back in the day, you had hardware, and then you had software that talked to it.

Then came BIOS, and D(isk)O(perating)S(ystem). In most systems, your software could only talk to the DOS (later called the OS because it was so much more than just about a disk).

DRIVERS happened because the BIOS didn't allow for enough variation and the DOS couldn't talk to all the things directly.

REAL operating systems didn't allow you to bypass the OS to talk to the driver or hardware, your driver talked to the OS, and your program got to the driver through the os. Microsoft's didn't do that -- and it took them years to get past the problems that resulted.

Now a new layer is emerging called the "VM" -- vm's aren't new, but standardized ones are. The heart of Java that makes it run once test anywhere is the "JVM" (java virtual machine). Microsoft's .NET stuff is really all about their own version of this they call the CLR (Common Language Runtime).

What the Eclipse Framework does, is it adds a great deal more meat to the FRONT END side of the JVM, and in combination, you have a place for programs to run (the JVM) and a presentation manager (Eclipse) which are both designed to provide the same environment regardless of which operating system they talk to. Its another layer of separation -- and you pay a penalty for that in performance of course so it has to be pretty valuable to be worth it.