ephraim@think.COM (ephraim vishniac) (06/01/88)
The description in the May 1988 _Outside_Apple_ makes MacWorkStation
sound like an almost ideal vehicle for whipping up a Mac front end to
a mainframe application. The price is a bit steep, but not a problem
if MWS is really good (i.e., is usable and will save us several months
of work). So my question is, how good is MWS? I'd like to hear the
good and the bad from anybody who's worked with it.
I'm especially interested in how well it can handle a situation such
as the following:
We're building an information retrieval system. The result of a
search is a list of articles, with their headlines visible. The user
should be able to browse through the articles in any way he pleases.
To improve apparent performance, we should anticipate his likely
choices by sending the first few paragraphs and the best few
paragraphs of each article while the user is pondering his next move.
Paragraphs will be cached in memory. If the user selects something
we've prefetched, we win. If he makes an unanticipated move, we
should be able to abort our transfer and act on his request promptly.
Will MWS allow us to carry on this kind of background activity? Does
it use error-detecting/correcting protocols? Does it allow
transmission of binary data or are you restricted by the underlying
network? What's the performance like on bulk data transfer?
Also, short of buying the whole package, is any technical
documentation available that might answer questions such as the above?
Ephraim Vishniac ephraim@think.com
Thinking Machines Corporation / 245 First Street / Cambridge, MA 02142-1214
On two occasions I have been asked, "Pray, Mr. Babbage, if you put
into the machine wrong figures, will the right answers come out?"han@Apple.COM (Byron Han, Licensed To Dream) (06/01/88)
In article <21441@think.UUCP> ephraim@think.com (ephraim vishniac) writes: > >Also, short of buying the whole package, is any technical >documentation available that might answer questions such as the above? > Contact Apple Licensing for information. I believe that there may be a 90 day free trial period going on right now. You'd have to check for sure. This applies to corporations/institutions, not individuals. Hope this helps. -- Byron Han, Licensed to Dream. Macintosh - One Small Step For Apple. Apple Computer, Inc. MS 27Y ----One Giant Leap for Humankind.---- ATTnet:408-973-6450 applelink:HAN1 domain:han@apple.COM MacNET:HAN GENIE:BYRONHAN COMPUSERVE:72167,1664 UUCP:{sun,voder,nsc,decwrl}!apple!han
rekieta@Apple.COM (Paul Rekieta) (06/02/88)
In article <21441@think.UUCP> ephraim@think.com (ephraim vishniac) writes: > > (Stuff about MacWorkStation) >of work). So my question is, how good is MWS? I'd like to hear the >good and the bad from anybody who's worked with it. > MWS is being used by many internal MIS development teams. Some, such as CITIBANK in New York, have been written up in the Mac weeklies. Others are using it for internal projects. A particullarly interesting application at a "major northern university" is a campus wide mail and directory system, as well as a campus map which shows the building the professor is in. >I'm especially interested in how well it can handle a situation such >as the following: > > (Description of an information retrieval system) > >Will MWS allow us to carry on this kind of background activity? Does >it use error-detecting/correcting protocols? Does it allow >transmission of binary data or are you restricted by the underlying >network? What's the performance like on bulk data transfer? > MWS is perfect for the type of application you describe. You would first create a list window with the article titles. Then you can begin creating invisible windows (for your pre-fetched articles) and send text to those windows in 512 byte messages. User events will be sent as they occur. Your remote program must be prepared to accept a limited number of user events. MWS itself is protocol independent. We do not yet offer an error-free protocol, but expect to soon. Binary transmission is protocol dependent but again could be implemented in a custom communications module. >Also, short of buying the whole package, is any technical >documentation available that might answer questions such as the above? > Documentation may be available from APDA soon, contact Apple Software Licensing for more information.
joachim@iravcl.ira.uka.de (06/02/88)
In article <21441@think.UUCP>, ephraim@think.COM (ephraim vishniac) writes: > I'm especially interested in how well it can handle a situation such > as the following: > [...] I think MWS is not the product for you. Of course you can do that, but you'll have to write external commands to do that. The basic operation of MWS is the user wants something, the host sends something. What you want to do requires a lot of history information or caching. There are two other problems with MWS: (1) your MWS application cannot have documents itself. It can process TEXT and MacWrite documents, but there is no double-clicking. (2) The transport layer supports no umlauted characters via transport method 2, you must use ADSP or the binary method (which is in general useless, because it assumes 8 bit, no XOn/XOff). Joachim Lindenberg, University of Karlsruhe Federal Republic of Germany - West Germany.
ephraim@think.COM (ephraim vishniac) (06/04/88)
In article <144@iravcl.ira.uka.de> joachim@iravcl.ira.uka.de writes: >In article <21441@think.UUCP>, ephraim@think.COM (ephraim vishniac) writes: >> I'm especially interested in how well it can handle a situation such >> as the following: >> [...] >I think MWS is not the product for you. Of course you can do that, >but you'll have to write external commands to do that. I don't have any problems with that. What I'm hoping to do is to write significantly less with MWS than I would without it. >(1) your MWS application cannot have documents itself. It can process > TEXT and MacWrite documents, but there is no double-clicking. Why is this so? If I add FREFs to the bundle of my MWS application, won't that let make my own types of double-clickable documents? Or is there no internal hook to let me do my own open-document processing when these added types are opened? I'm still waiting for information that Apple Software Licensing is sending me. Once I get that, I'll post a summary of what I've learned. Ephraim Vishniac ephraim@think.com Thinking Machines Corporation / 245 First Street / Cambridge, MA 02142-1214 On two occasions I have been asked, "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?"
rekieta@Apple.COM (Paul Rekieta) (06/04/88)
In article <144@iravcl.ira.uka.de> joachim@iravcl.ira.uka.de writes: >In article <21441@think.UUCP>, ephraim@think.COM (ephraim vishniac) writes: >> I'm especially interested in how well it can handle a situation such >> as the following: >> [...] > >I think MWS is not the product for you. Of course you can do that, but >you'll have to write external commands to do that. The basic operation >of MWS is the user wants something, the host sends something. What >you want to do requires a lot of history information or caching. > I don't think you need external commands. The basic operation of MWS is to be passive and wait for either commands from the host, or events generated by the user, primarily two event types: Menu selections, and Dialog events (ie button pushes). It is reasonable for a MWS host program to send commands to MWS while polling for events coming back. >There are two other problems with MWS: >(1) your MWS application cannot have documents itself. It can process > TEXT and MacWrite documents, but there is no double-clicking. MWS can have documents containing local dialogs, menus, login scripts and other host defined resources. Double-clicking one of these documents will start MWS and execute a pre-defined login script. >(2) The transport layer supports no umlauted characters via transport > method 2, you must use ADSP or the binary method (which is in > general useless, because it assumes 8 bit, no XOn/XOff). > The transport problem will be solved soon. We are working on a comm module to send binary data in 7 bit mode allowing Xon/Xoff and errr detection.
rekieta@Apple.COM (Paul Rekieta) (06/04/88)
In article <21606@think.UUCP> ephraim@vidar.think.com.UUCP (ephraim vishniac) writes: > >Why is this so? If I add FREFs to the bundle of my MWS application, >won't that let make my own types of double-clickable documents? Or is >there no internal hook to let me do my own open-document processing >when these added types are opened? > There is no internal hook to do your own open-document processing. What would you store in your custom documents?
joachim@iravcl.ira.uka.de (06/10/88)
In article <11584@apple.Apple.Com>, rekieta@Apple.COM (Paul Rekieta) writes: > In article <144@iravcl.ira.uka.de> joachim@iravcl.ira.uka.de writes: > >>There are two other problems with MWS: >>(1) your MWS application cannot have documents itself. It can process >> TEXT and MacWrite documents, but there is no double-clicking. > > MWS can have documents containing local dialogs, menus, login scripts > and other host defined resources. Double-clicking one of these documents > will start MWS and execute a pre-defined login script. I think you didn't get the point. An MWS application is a document by itself and cannot have other application defined documents by itself. The application I am thinking about is mail - the host/client application per se - and the documents could be old mail, drafts, etc. Another application could be a database query template or report that is saved on the user's machine. > >>(2) The transport layer supports no umlauted characters via transport >> method 2, you must use ADSP or the binary method (which is in >> general useless, because it assumes 8 bit, no XOn/XOff). >> > > The transport problem will be solved soon. We are working on a comm > module to send binary data in 7 bit mode allowing Xon/Xoff and errr > detection. Great! This will greatly improve MWS. - Joachim Lindenberg, Dept. of Computer Science, University of Karlsruhe Sommerstrasse 4, 7500 Karlsruhe 1, Federal Republic of Germany joachim@ira.uka.de, joachim@germany.csnet, ..!mcvax!unido!uka!joachim