Ok, just for snicks, let's say we have agree on most things up to this point, let's drill on one of them a tad more. As a starting point, let me pick one thing you said Bill, and start with that.
" . . . although I will admit that so far Microsoft has written the best client for Exchange." I don't disagree. Although I had a lot of issues with the way David operated independently and in effect torpedoed Capone (the old Exchange client), Outlook has gotten a lot better and most of the early issues that I had with it have been resolved. It finally got type ahead buffers (WordStar had them back in the '80s), but it probably is safe to say that right now, Outlook is the bet that is available. But, does that make it either good or what we need? Those are two very different questions. Almost anything can be defined as good, if you put it in the right context. And certainly in the case of Outlook there is an obvious "right' context:" a legacy Wintel box. Unfortunately, that is both a diminishing percentage of the total universe of client devices, and it is not the platform of choice for most new business process support. This latter point is the one that counts. In most industries, where there is an automation element to a new process improvement effort, the focus tends to be on better integration of back-end systems, and on simplified highly mobile clients with embedded systems (typically CE, Palm, Wind River or something proprietary). The point of neutrality among these new systems, if they have a "head" (as opposed to headless devices), tends to be a browser. That is where the vast majority of critical process improvement work is happening. This varies from one industry to another, but it is amazingly consistent. We are a combination of engineering, manufacturing, and product support services company. A lot of our automation support for engineering process improvement is happening in the Unix world, with some Wintel on the client side. But in manufacturing and customer/product support, high mobility is everything. In the other areas, there is some minor amount of innovation on Win2K tablets and Wintel boxes in places like tool cribs; but most of the focus is on PDA's, smart cell phones, CE tablets, CE data collection tools and even custom built special purpose CE boxes. MAPI does nothing for me in almost anything that is new. In fact, Exchange functionality being locked into MAPI is one of the bigger obstacles I have to overcome. The right answer has to be in a browser and run on top of http. It's the only thing that cuts across enough of what I need to support to make it worthwhile. That is not an operations nor a techie requirement. It is a business requirement. Now here is where it gets vicious. Think back into the 1980's pr early 90's when the mainframe boys and girls just did not get it. Back then, virtually 100% of automation support for business process improvement was on the PC. The problem was the the value stream. There is a book by Clayton Christensen of the Harvard business school that should be required reading for everyone in a tech career. What happens with a mature technology (like the PC is now) that the techies that run it end up being the primary customer interface to the suppliers. Back when Microsoft was young and feisty, they tended to sell their product directly to where the business needs existed. Yes they also mad their pitch to IS managers and existing mid-range and host systems people, but their friends were the people out on the front lines supporting business innovation. That is no longer the case. Now their primary interface is to the tech weenies in operations, not the innovators. Where do most new development requirements for Exchange come from? Sadly, it is from the operations folks. In some ways, this is an amazing sign of how successful Exchange has been. But, in other ways it is a disaster. The last people that seem to really understand what it is that their companies need, are the IS operations folks who are experts in legacy or incumbent technologies. If this had not been the case, Novell would have put a useful API on Netware, or IBM would have ported OV to NT, and both would have happened well before their respective nemeses got off the ground. This is why Christensen titled his book "The Innovator's Dilemma." Read it. Then take the pulse of your business to find out where the current biggest leaps in productivity are occurring, and what the role of automation is. Then get on the band wagon to dump MAPI and move on to http. Otherwise, prepare to become a dinosaur. -----Original Message----- From: East, Bill [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 21, 2002 1:01 PM To: Exchange Discussions Subject: RE: synchronizing OWA with OST or PST > -----Original Message----- > From: Dupler, Craig [mailto:[EMAIL PROTECTED]] > Sent: Thursday, March 21, 2002 12:32 PM > To: Exchange Discussions > Subject: RE: synchronizing OWA with OST or PST > > > Well I thought this had died with everyone having made their > points, but > apparently not. I thought that last response to my post was > so off the > point that it only underscored what I had said. Well isn't that flattering. > > I think this is where systems architects and operations folks > have their > most difficult problems in communicating with each other. It > is ok for an > operations view to be pressed that suggests that given the current > technology using a specific approach is a best practice. > However, that does > not translate into where it is best to take the product. > Agreed. > MAPI is a painful legacy at this point. I don't think anyone > is suggesting > that it should be ported to any other platform, including the > Pocket PC and > Windows CE families. We don't want it, and neither does > Microsoft. That > creates an interesting situation. Should the services in MAPI that go > beyond what is currently in IMAP4 and OWA be extended to > other platforms or > not, and if so, how? > Well of course. Dropping MAPI without providing more functionality would be just silly. > This is where I got bent. There was a rabid non-thinking > defense of the > status quo: a sort of I'm not giving up my MAPI until you > pull my cold dead > fingers from my keyboard" approach. That attitude is not defensible. > About the only technology arguments that I respect less than > those that > start "Linux is best . . ." or "Apple is best . . ." are the > ones that start > "Microsoft is best . . ." Exchange is a superior product > because it is > mostly very pragmatic in its design. When this stops to be true, it's > roadkill, and so are the sys admins that make their living > off of it. I > don't think that is in the best interests of anyone on this list. Well I hope you don't think I feel that way. I tend to be fairly platform-neutral, although I will admit that so far Microsoft has written the best client for Exchange. > > Evolving trends in security systems suggest that the one high > level protocol > that looks like it has the best shot at transiting the > greatest number of > transport links, and being useful for the widest possible number of > non-streaming media applications is http. Similarly, the > well equipped > browser has displaced all other offerings and attempts to > build platform > neutral systems that still work well with market-centric systems (i.e. > Wintel). Interesting perspective, but I don't see the basis for your conclusions. Sure, port 80 is passed by most firewalls, but it is also highly insecure, stateless, and has significant overhead (SSL, of course, still has the latter two problems with even more overhead). Similarly, the "well-equipped browser" has so far failed to replace certain applications - word processors, spreadsheets, and mailtools among them. The average browser does not have facilities built into it which can do local storage or indexing, and these are things that you need. I find it significant that Microsoft has _not_ tried to fold their mailtool into Internet Explorer, instead bundling it as a seperate application (Outlook Express). So I would have to say that both http and Web browsers have too many historical restraints to effectively do what you want. > This can only lead to one conclusion. MAPI clients are not > strategic. They > have at best a limited future. The premier client protocol > for Exchange, if > it is to survive, has to be http. Get over it. Adapt and thrive. > I'd be willing to bet you a dollar that the successor to MAPI will not be http. Microsoft may decide to embrace and extend IMAP, or may design a new protocol from the ground up. And the client will run as a seperate process, not in the browser (unless it's as an ActiveX component). I'd say actually that we are starting to move away from the "run everything in a browser" mentality. I'm finally starting to see some exceptional programming done in Java although of course if you want speed and reliability you still stick with one of the C variants. Browsers are great for applets - I appreciate the capability to interface with a router through one - but in the end are a bit too Procrustean for my tastes. > > -----Original Message----- > From: East, Bill [mailto:[EMAIL PROTECTED]] > Sent: Thursday, March 21, 2002 6:25 AM > To: Exchange Discussions > Subject: RE: synchronizing OWA with OST or PST > > > Jumping Jiminey. I guess I am. > > It's just that Dupler fellow. I get all excited. > > -- > be - MOS > > > > "This is Vergon 6." -Professor > "Bah." -Amy > "It's a sunny little doomed planet, inhabited by a number of > frisky little > doomed animals." -Professor > > > > -----Original Message----- > > From: Soysal, Serdar [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, March 20, 2002 5:58 PM > > To: Exchange Discussions > > Subject: RE: synchronizing OWA with OST or PST > > > > > > A little behind on your reading Bill? > > > > Serdar Soysal > > > > > > -----Original Message----- > > From: East, Bill [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, March 20, 2002 3:43 PM > > To: Exchange Discussions > > Subject: RE: synchronizing OWA with OST or PST > > > > > > > -----Original Message----- > > > From: Dupler, Craig [mailto:[EMAIL PROTECTED]] > > > Sent: Tuesday, February 05, 2002 1:33 PM > > > To: Exchange Discussions > > > Subject: RE: synchronizing OWA with OST or PST > > > > > > > > > Yes, it works well. That was never the point. But, just > > like a MAPI > > > session, you should be able to do a synch while in browse > > mode on OWA. > > > > > I'm puzzled by this approach, Craig. > > > > Let's say you're at an airport kiosk. You're going to > > download the synch > > file, then what? Copy it to a floppy? What if it's more that > > 1.44MB? What if > > the kiosk doesn't have a floppy drive? If you're using a PDA, > > how do you > > transfer the file to there? > > > > OTOH, let's say you're hooked into a WLAN in the Executive > > Lounge from your > > own laptop or PDA. You can then fire up your VPN software, > > connect into your > > LAN and synch using the copy of Outlook on your PC. If you don't use > > Outlook, as many others have pointed out, you can use an > IMAP client. > > > > Synchronization to an OST presumes that you have Outlook > > installed, so why > > re-create the wheel? OWA was built to be run from any browser > > anywhere (I > > can even convince Opera to load it if I work at it), but like > > most Web-based > > services, presumes a connection for the duration of the session. > > > > > > > I don't get it. Why are you guys arguing in favor of keeping > > > a small and > > > extremely useful feature out of the product? Is it a "we're > > > tough, we can > > > take it" sort of thing, or what? > > > > > > > Implementation of this isn't trivial, and there already > exist multiple > > better ways to do what you want. So why would Microsoft spend money > > developing another one? > > > > > Or maybe it is that you've bought into the view that small > > > machines should > > > only be used as companions to "real" machines. > > > > Well, no. If you have an IMAP/MAPI client and a Web browser > > on your handheld > > you're in good shape. But your Web browser sucks as a > > mailtool, so why not > > use the IMAP/MAPI client? > > > > > Sheesh, I > > > thought that > > > attitude died back in the 80's when the mainframe crowd tried > > > to convince > > > everyone that OV, HP Desk and All-In-1 were the "real" > > > workgroup messaging > > > systems, and that LAN mail should be relegated to simple > > departmental > > > messaging only tasks. > > > > > > It's amazing. The PC guys have grown up to become the > > > dinosaurs that they > > > displaced. > > > > > > > I resent that implication. I have not become a PDP/11. > > > > _________________________________________________________________ > > List posting FAQ: http://www.swinc.com/resource/exch_faq.htm > > Archives: http://www.swynk.com/sitesearch/search.asp > > To unsubscribe: mailto:[EMAIL PROTECTED] > > Exchange List admin: [EMAIL PROTECTED] > > > > > > _________________________________________________________________ > > List posting FAQ: http://www.swinc.com/resource/exch_faq.htm > > Archives: http://www.swynk.com/sitesearch/search.asp > > To unsubscribe: mailto:[EMAIL PROTECTED] > > Exchange List admin: [EMAIL PROTECTED] > > > > _________________________________________________________________ > List posting FAQ: http://www.swinc.com/resource/exch_faq.htm > Archives: http://www.swynk.com/sitesearch/search.asp > To unsubscribe: mailto:[EMAIL PROTECTED] > Exchange List admin: [EMAIL PROTECTED] > > _________________________________________________________________ > List posting FAQ: http://www.swinc.com/resource/exch_faq.htm > Archives: http://www.swynk.com/sitesearch/search.asp > To unsubscribe: mailto:[EMAIL PROTECTED] > Exchange List admin: [EMAIL PROTECTED] > _________________________________________________________________ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Archives: http://www.swynk.com/sitesearch/search.asp To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin: [EMAIL PROTECTED] _________________________________________________________________ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Archives: http://www.swynk.com/sitesearch/search.asp To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin: [EMAIL PROTECTED]
