gnue-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnue-dev] Halloween 2: Appserver's Jobs


From: Reinhard Mueller
Subject: [Gnue-dev] Halloween 2: Appserver's Jobs
Date: 03 Nov 2002 11:01:40 +0100

Hello again,

The next topic on the GNUe Hacker's meeting was to create a list of
things Appserver will do and a list of things Appserver won't do.

Here they are:
--------------

Appserver will do:

(high priority)
* Store persistent business objects in the database (basically done)
* Abstract data access from SQL (basically done)
* Do calculations and other stuff in procedures (partly done)
* Fake python objects to procedures
* Provide a management interface or a management API
* Merge business object definitions from different modules

(medium priority)
* Manage the database schema in the backend
* Provide logging facilities
* Automatically start reports

(low priority)
* Ensure integrity of the data
* Care for authentification 
* Care for security
* Batch processing (which we defined as running a job that is longer
than the user wants to wait interactively)
* Automatic (cron-like) execution of jobs
* Manage revisions of business object definitions
* Access live data from other applications (over DBDriver)
* Load balancing, replication

(low priority might mean that _definition_ is still high priority, but
_implementation_ is lower priority)

Appserver will not do:

* Directly generate HTML (JForms and Reports will do that)
* Generate "designed" Form and Report definitions (Designer will do
that)
* Generate "standard" Forms and Reports from the object definitions
(Forms and Reports will do that) - but Appserver will provide the
necessary data for Forms and Reports to generate these "standard"
layouts
* Provide a OQL or SQL like Query language - there will be a separate
client application that will do that
* In small installations work as a report server - however for small
installations Appserver and Reportserver could maybe be linked together
to "look like" a single server
* Import legacy data from other applications (Integrator will do that)
* Export data in different formats (Integrator and Reports will do that)
* Workflow (some modules outside Appserver will do that, or even some
business objects might exist to manage workflow)


The most important things (read the next steps to implement) are
* the strategy how to merge object definitions from different modules
* finish the process calling system
* create a language interface that makes business objects look like
python objects to process code
* provide a way to define business objects

However, we agreed that we have to do these further things before
implementation can continue:
* Redefine the API between Appserver and Forms/Reports, as the current
API has performance issues
* Define the core modules of Appserver, (slightly) update the Appserver
Diagram and define the APIs between the modules.

To be continued...

-- 
Reinhard Mueller
GNU Enterprise project
http://www.gnue.org

Attachment: signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil


reply via email to

[Prev in Thread] Current Thread [Next in Thread]