Re: [Gnue-dev] GNUe-Integrator

[Stanley A. Klein]

Jan -

Comments interspersed.


Stan Klein


At 06:43 AM 11/21/2002 -0500, Jan Ischebeck <address@hidden> wrote:

>
>Am Donnerstag, 14. November 2002 19:20 schrieb Stanley A. Klein:
>...
>>
>> 2.  I don't know if it is Integrator or something else, but it might be a
>> good idea to be able to store data in XML files and to connect forms and
>> reports to those files just as though as the data were in a database, i.e.,
>> changing the data would have the effect of editing the XML files.  I can
>> think of security issues that would be solved by being able to do this.
>> For example, something like this could simplify the maintenance of secure
>> patient medical records or student educational records, given some of the
>> US legal requirements for privacy in patient and student records.  (BTW, I
>> think the European requirements for privacy are more stringent than the US
>> requirements, and I suspect the same technology would help satisfy the
>> European requirements.)
>I don't see a big difference in security between a local, well secured 
>database and XML files in a filesystem. The only way to add security and
make 
>it to comply to European privacy requirements would be to load the data from 
>a smartcard, edit it and store it back again.

a.  I think the important aspect is "well secured."  It is easier to secure
XML files in a file system than the equivalent data in a database.  The
database system looks like an application to the operating system.  Most
databases are less well secured than operating system files, especially for
access controls that are not actually being enforced (under the covers) by
the operating system.  I agree that if the database system is as secure as
the operating system, there is not much difference, but the likelihood is
that the operating system will be much more secure.  Certainly, if the
operating system is *not* secure there is nothing that can be done to make
the database system secure, regardless of what security features are
programmed into the database system and the application.

b.  There is a project called Rule Set Based Access Control (for Linux)
that supports numerous security policies, one of which is supposedly
designed to comply with European privacy requirements.  The RSBAC folks
were involved in the early days of the Linux Loadable Security (kernel)
Module effort (for development kernel 2.5 and operational kernel 2.6), but
their web page doesn't indicate current activity in that area.  Otherwise,
installing RSBAC would require a kernel patch and recompilation.  I don't
think they go as far as requiring separate smartcard storage.

>
>IMHO editing XML files won't be done by integrator but with an XML-file 
>"database driver".
>

Well, I said I wasn't sure if this was an Integrator issue.  It probably
belongs elsewhere.  :-)


>>
>> 3.  I think that what you describe can do this, but in the past I have had
>> a need to "version" a database, i.e., create multiple versions of a
>> database, primarily as cases for math modeling.  (I once built a system
>> performance model in SQL and ran it against different versions of a
>> database that contained system component capacity parameters  and system
>> workloads.  Because the DBMS was Oracle, and because that version of Oracle
>> made it somewhat difficult to maintain multiple versions of the same
>> database, I had to export the database to ASCII files and reload the
>> database from ASCII every time I wanted to change versions.)
>
>I don't know, if I understand you right. You speak of a database 
>change/migration szenario? 
>IMHO Integrator will be able (with the help of designer) to load two schema 
>definitions and migrate the schema and the data in the database from the
first 
>to the second database schema.


Perhaps I need to explain it in more detail.  I was doing a system
performance analysis.  The schema was constant, but the database changed
according to a number of "what if" design and workload cases.  The database
consisted of about 15 tables that described the system design and workload.
 The calculation of system performance consisted of creating about 35
additional views and tables that did certain joins of the design and
workload data and calculated statistical parameters for queuing formulas.

Each design/workload "what if" case consisted of a different version of the
database data with certain of the values changed from the base case in
different ways.  The performance analysis consisted of loading the "what
if" case into the database from ASCII files and then running the SQL to
create the additional views and tables that implemented the queuing formula
calculations.


>
>> 4.  For what it's worth, I recently needed some code to convert a Dbase
>> file for eventual use in GNUe.  I did some searching and found some code in
>> one of the Python repositories that converts from Dbase format to an SQL
>> equivalent. Let me know if it would be useful for Integrator.
>
>That would be quite useful for integrator. We would modify it to become 
>another dbdriver. 

I will send you a copy.