home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / sys / next / programm / 7268 < prev    next >
Encoding:
Text File  |  1992-11-17  |  2.6 KB  |  49 lines

  1. Newsgroups: comp.sys.next.programmer
  2. Path: sparky!uunet!charon.amdahl.com!pacbell.com!ames!saimiri.primate.wisc.edu!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!ssircar@canon.com
  3. From: ssircar@canon.com (Subrata Sircar)
  4. Subject: Re: CoreServer
  5. Message-ID: <9211180053.AA13033@alychne-nc.canon.com>
  6. Sender: daemon@magnus.acs.ohio-state.edu
  7. Reply-To: ssircar@canon.com
  8. Organization: The Ohio State University
  9. Date: Wed, 18 Nov 1992 00:55:31 GMT
  10. Lines: 37
  11.  
  12.  
  13. For starters, why would you want to separate the "core" of your app from the  
  14. UI?  Well, the obvious answer is "to make the core portable among different  
  15. operating systems and environments".
  16.  
  17. That is certainly a big reason.  More generally, this is true if you wish to  
  18. write a core portable among multiple interfaces (writing X code for Motif and  
  19. OpenLook, or something).  In other words, one would do this to buffer the core  
  20. from the interface driving it.
  21.  
  22. This comes up when providing an API for your application; the API usually  
  23. duplicates functionality obtained in the application, but allows other  
  24. services/apps to access its power without going through the user interface.  In  
  25. a sense, the API is a second, more powerful but less accessible interface to  
  26. the application.
  27.  
  28. Under NeXTstep, this problem is somewhat more urgent with the advent of  
  29. Distributed Objects.  Making your app accessible via an API that someone can  
  30. access from another machine on the same network allows tremendous leverage and  
  31. the possibility of developing lightweight objects which can do major tasks in  
  32. combination with each other.  If your app is entirely menu/panel driven, or  
  33. stores state in the UI (very common with TextFields, FormCells, etc) then it  
  34. can be hard to allow someone to leverage your work.  If, on the other hand,  
  35. your app stores all its own state and accesses the UI through another object  
  36. (which in itself uses the core's API), then Distributed Objects is a snap.
  37.  
  38. The reason I'm interested in this core-UI thing is the last; I'm interested in  
  39. developing objects and palettes for Canon Information Systems to run various  
  40. scanning devices.  Packing these objects as NeXTstep palettes means I have to  
  41. figure out what kind of an interface to give the developer, and how to provide  
  42. a flexible interface to the scanner for Distributed Objects.
  43.  
  44. ---
  45. Subrata Sircar|ssircar@canon.com (NextMail ok)|Prophet & SPAMIT Charter Member
  46. Canon Information Systems and I do not share the same views on everything.
  47. "I'm just mad that I missed the sexual revolution." - me
  48. "Yes, but you dress much better as a result." - Mike
  49.