gnue/appserver/doc/whitepaper whitepaper.texi

[Jason Cater]

CVSROOT:        /cvsroot/gnue
Module name:    gnue
Changes by:     Jason Cater <address@hidden>    03/01/21 01:59:17

Modified files:
        appserver/doc/whitepaper: whitepaper.texi 

Log message:
        minor grammar and punctuation corrections

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gnue/gnue/appserver/doc/whitepaper/whitepaper.texi.diff?tr1=1.6&tr2=1.7&r1=text&r2=text

Patches:
Index: gnue/appserver/doc/whitepaper/whitepaper.texi
diff -c gnue/appserver/doc/whitepaper/whitepaper.texi:1.6 
gnue/appserver/doc/whitepaper/whitepaper.texi:1.7
*** gnue/appserver/doc/whitepaper/whitepaper.texi:1.6   Sat Nov 23 15:53:40 2002
--- gnue/appserver/doc/whitepaper/whitepaper.texi       Tue Jan 21 01:59:17 2003
***************
*** 30,36 ****
  @author Reinhard M@"uller
  @page
  @vskip 0pt plus 1filll
! Copyright @copyright{} 2002 Free Software Foundation
  
  Permission is granted to copy, distribute and/or modify this document
  under the terms of the GNU Free Documentation License, Version 1.1
--- 30,36 ----
  @author Reinhard M@"uller
  @page
  @vskip 0pt plus 1filll
! Copyright @copyright{} 2002-2003 Free Software Foundation
  
  Permission is granted to copy, distribute and/or modify this document
  under the terms of the GNU Free Documentation License, Version 1.1
***************
*** 79,103 ****
  GNUe Appserver must be GPL and must be built with truly free tools.
  
  @item Stability
! GNUe Appserver must be reasonable stable. For a mission-critical
! application in a business, reasonable stable means very stable.
  
  @item Security
! GNUe Appserver must be reasonable secure.
  
  @item Maintainability
  The code base of GNUe Appserver itself must be and remain maintainable
  by the development team, and the code must be clear enough to allow
! interested programmers to adapt it, fix bugs or even take over maintenance
  of a part of Appserver.
  
  @item Configurability
  GNUe Appserver must be configurable and reconfigurable dynamically, centrally,
! without programming skills, without downtime, and in seperate "layers"
  for various levels of specification.
  
  @item Performance
! GNUe Appserver must perform reasonably with large quantities of users
  and/or data.
  
  @item Database Independence
--- 79,103 ----
  GNUe Appserver must be GPL and must be built with truly free tools.
  
  @item Stability
! GNUe Appserver must be reasonably stable. For a mission-critical
! application in a business environment, reasonably stable means very stable.
  
  @item Security
! GNUe Appserver must be reasonably secure.
  
  @item Maintainability
  The code base of GNUe Appserver itself must be and remain maintainable
  by the development team, and the code must be clear enough to allow
! interested programmers to adapt it, fix bugs, or even take over maintenance
  of a part of Appserver.
  
  @item Configurability
  GNUe Appserver must be configurable and reconfigurable dynamically, centrally,
! without programming skills, without downtime, and in separate "layers"
  for various levels of specification.
  
  @item Performance
! GNUe Appserver must perform reasonably well with large quantities of users
  and/or data.
  
  @item Database Independence
***************
*** 123,131 ****
  
  @section Business Objects
  
! GNUe Appserver allows definition of data entities (for example name and
  address of a customer) and of program code to perform on such entities
! (for example how to build the address line from country, zipcode and city).
  
  The combination of a data entity with all code functions that can be performed
  on the entity is called a @dfn{business object}.
--- 123,131 ----
  
  @section Business Objects
  
! GNUe Appserver allows definition of data entities (for example, name and
  address of a customer) and of program code to perform on such entities
! (for example, how to build the address line from country, zipcode, and city).
  
  The combination of a data entity with all code functions that can be performed
  on the entity is called a @dfn{business object}.
***************
*** 176,195 ****
  @section Procedures
  
  A procedure is code performed on an object. Procedures can have parameters
! of any attribute type (string, number, reference, etc.). Every method has
! the paramter @dfn{self}, that is the object to operate on, as a parameter.
  
  @section Modules
  
  Modules define namespaces for classes, properties, and procedures. When
! module A defines a class and some properties and procedures for the class,
! module B can extend the class with new properties. Another module C can
! independently extend the class, without taking care about not using the
! same property names as module B, because all modules have their own namespace.
  
  @section Qualified class, property and procedure names
  
! Class, property and procedure names can be preceded by a module name to
  override the current module context. In this case, the module name is
  separated by an underscore (_). This results in the rule that neither
  a module name nor a class, property or procedure name may contain an
--- 176,195 ----
  @section Procedures
  
  A procedure is code performed on an object. Procedures can have parameters
! of any attribute type (string, number, reference, etc.). Every method is 
passed
! a parameter, @dfn{self}, that identifies the object to operate on.
  
  @section Modules
  
  Modules define namespaces for classes, properties, and procedures. When
! module A defines a class with various properties and procedures,
! module B can extend the class with new properties. Another module, C, can
! independently extend the same class, without fear of conflicting with module 
B. 
! All modules have their own namespace.
  
  @section Qualified class, property and procedure names
  
! Class, property, and procedure names can be preceded by a module name to
  override the current module context. In this case, the module name is
  separated by an underscore (_). This results in the rule that neither
  a module name nor a class, property or procedure name may contain an
***************
*** 232,241 ****
  @code{sales_lastInvoice.number} is the number of the last invoice of the
  customer. We could call that an @dfn{indirect property}.
  
! @code{sales_lastInvoice.items} is an indirect property, which is a list
! property.
  
! And if yet another module "acct" extends the invoice_header class by a
  property "paid", then
  
  @code{sales_lastInvoice.acct_paid} could be a boolean property that tells you
--- 232,240 ----
  @code{sales_lastInvoice.number} is the number of the last invoice of the
  customer. We could call that an @dfn{indirect property}.
  
! @code{sales_lastInvoice.items} is an indirect list property.
  
! And if yet another module, "acct", extends the invoice_header class by a
  property "paid", then
  
  @code{sales_lastInvoice.acct_paid} could be a boolean property that tells you
***************
*** 246,253 ****
  @section Bound Procedures
  
  @dfn{Bound procedures} are procedures that are automatically called upon
! occurance of defined @dfn{events}, for example on every change of a
! specific property, or before a commit of a changed object.
  
  Bound procedures are always procedures of the object where the event occurs.
  Because every module can extend any class with a procedure of arbitary name,
--- 245,252 ----
  @section Bound Procedures
  
  @dfn{Bound procedures} are procedures that are automatically called upon
! occurance of defined @dfn{events}; for example, on every change of a
! specific property or before a commit of a changed object.
  
  Bound procedures are always procedures of the object where the event occurs.
  Because every module can extend any class with a procedure of arbitary name,
***************
*** 338,344 ****
  Interface to check whether the connected user may access this class.
  
  @item
! If both is OK, the Object Server translates a class name into a table name.
  This will include adding a prefix to enable different application modules
  to have their own namespace.
  
--- 337,343 ----
  Interface to check whether the connected user may access this class.
  
  @item
! If both are OK, the Object Server translates the class name into a table name.
  This will include adding a prefix to enable different application modules
  to have their own namespace.
  
***************
*** 360,366 ****
  Eventually, the Data Interface will support creating and extending tables
  "on the fly", which means that reading a recordset with attributes that
  don't exist in the database will automagically add the missing columns to
! the table.  This will of course be parameterized.
  
  The Data Interface operates strictly on a table/row interface and doesn't
  know anything about objects, properties and procedures.
--- 359,366 ----
  Eventually, the Data Interface will support creating and extending tables
  "on the fly", which means that reading a recordset with attributes that
  don't exist in the database will automagically add the missing columns to
! the table.  This will, of course, be an optional feature that can be turned 
! off.
  
  The Data Interface operates strictly on a table/row interface and doesn't
  know anything about objects, properties and procedures.
***************
*** 376,382 ****
  The Code Adapter will abstract the calls to business methods written in
  the different languages.
  
! Python will be the only language to support here for probably a long time.
  
  The Code Adapter, or at least parts of it, will reside in GNUe Common.
  
--- 376,382 ----
  The Code Adapter will abstract the calls to business methods written in
  the different languages.
  
! Python will be the only language supported for the near future. 
  
  The Code Adapter, or at least parts of it, will reside in GNUe Common.
  
***************
*** 457,468 ****
  Interface.
  
  For example, the Python Language Interface (which will be the first one
! to be implemented) lets you access business objects just like they were
  normal Python objects.  Procedures written in Python will use this
  interface to access business objects in a rather straightforward way.
! But also other parts of the Application Server can use the Language Interface,
! if they want to access business objects, for example the system objects
! defining classes or access rights.
  
  @raisesections
  
--- 457,468 ----
  Interface.
  
  For example, the Python Language Interface (which will be the first one
! implemented) lets you access business objects as if they are
  normal Python objects.  Procedures written in Python will use this
  interface to access business objects in a rather straightforward way.
! Other parts of the Application Server, such as system objects defining 
! classes or access rights, can also use the Language Interface 
! to access business objects.
  
  @raisesections