News and commentary from the cross-platform scripting community.
	Mail Starting 3/27/97

---

From: dpreed@reed.com (David P. Reed);
Sent at 3/29/97; 7:57:05 AM;
linguistic predictions

Random thoughts inspired by your remark about newspapers on the web being called papers:

- of course, we still dial touch-tone phones, post messages in event queues, page people over radio beepers, etc. And we have TV news 'magazines' like 20/20 and HardCopy.

- "when a newspaper is on the web" may yet evolve to "when newspapers are webs" (we'll have to figure out the scope of the published entity called the 'New York Times' ... where is the boundary?)

- there's an old joke: "never insult someone who buys ink by the barrel." will kids born in 2010 understand that joke? or will we have to translate it to "never insult someone who has owns a server farm on the backbone"?

---

From: Patrick.Breitenbach@aexp.com (Patrick Breitenbach);
Sent at 3/28/97; 11:32:09 AM;
News & Updates

Dave, I've always disliked chronological newsy lists on the internet that are grouped by month. For instance, I envision that when I return to my computer next Tuesday, April 1, a number of these pages such as Maccentral, Macintouch and scripting.com will have archived up March and moved on to April and I'll need to dig slightly to get the last 4 days of March. Additionally, pages like scripting.com sometimes get pretty long near the end of the month. Granted everyone has his/her personal needs, it would seem a more sensible system would be to show the last x days (10 or 15 for content such as yours) worth. Archives could still be organized by month.

---

From: pholmes@ucsd.edu (Preston Holmes);
Sent at 3/27/97; 10:12:10 AM;
coda comments

I have to say that Coda makes me very nervous.

It makes me nervous because designers _will_ like it so much that they may use it. The problem is that there is no standard for Java pages.

Coda says its runtime is only 200K and only needs to be downloaded once. Then coda pages load as fast as HTML.

OK, but what happens when we have a couple dozen companies going the Coda way, but each with their own engine.

Now I have all these different runtimes, designers have to choose - it becomes chaos. Would Coda let me build a design tool that uses the Coda runtime, I doubt it, they would have to protect themselves.

HTML may be bastardized, and it may not be a designers wet dream, but it still has advantages over the approach Coda is taking.

---

From: jroepcke@main.roepcke.com (Jim Roepcke);
Sent at 3/27/97; 10:10:03 AM;
Re:The OpenDoc Lesson

Actually, SOM isn't very new at all! (Except for the Mac)

SOM has been around since the early 90's, and has been the superclass of OS/2's Workplace Shell since OS/2 2.0, way way back in 1992 or so.

SOM is in use in OS/2, AIX, Win32, and probably in AS/400 and OS/390 too. I belive it's also avilable for a few other UNIXes as well, stuff from Tandem, etc.

SOM is actually very easy to program with/for, and the benefits of using it properly are huge. (SOM and DSOM are CORBA ORBs, for example!)

Anyway, enough D/SOM evangelism... Back to OpenDoc.

Unfortunately, the rest of OpenDoc was not so nice to work with, for a developer at least...

If there's a silver lining with OpenDoc right now, it's that it will still be included in the MacOS and OS/2 Warp, and that the moving target seems to have stopped now.

As completely backwards as it seems, now is a good time to start a low priority project to play with OpenDoc as an end-user, and maybe create some cool parts too.

I still think OpenDoc is a good tool for the end-user, and a great tool for corporations, when it does what it was made to do. There are already a lot of good OpenDoc parts available that people can use.

OpenDoc is dead! Long live SOM! :-) (And Java!)

---

From: Johnable@aol.com;
Sent at 3/27/97; 8:17:32 AM;
CLUNKY DOWNLOADS

Can't imagine that you don't know that you can set Stuffit Expander preferences to place completed downloads in a folder of your choice and send binhex and .sit file to the trash. Try it, you'll like it!

---

From: peter@stairways.com.au (Peter N Lewis);
Sent at 3/18/97; 10:05:15 AM;
Re:The OpenDoc Lesson

The problem with OpenDoc was simply that it was over-engineered. Look at every part of OpenDoc and you'll see a concentration on technology instead of a workable product. Every piece of OpenDoc from SOM to Bento is new, complex technology, so it's no wonder the final product was big and slow and difficult to program for (for example, I could not program for it at all using Pascal). They gave too many developers a good reason not to develop for it.

All developers inevitably have more work to do that can be done, more future projects than can possibly ever be written, so we must constantly be allocating resources to the projects that give us the most value for effort. For almost all of us, OpenDoc failed, either because the effort was too much or the value too little. The effort was high because of the reliance on new technology, and the value too little because OpenDoc had low user adoption, because it was big and slow, in turn again because of its reliance on new technology.

The same cause of death applies to Copland and PowerTalk. As developers we need to constantly be weary of this slow death.

It's a shame, OpenDoc was a good idea, is a good idea, but the implementation was too bogged down to live up to the idea.