Mr. Project DB

>> I think if MrProject is going to extend to the scale that's being
discussed
>> here (to cover large scale engineering projects or as the project
management
>> system for a multinational), the XML file format has to be replaced by a
>> database backend. Having a flat file sitting behind MrProject is what
limits
>> it to small scale. Given the availilibity of high quality open-source
DBMS'
>> (mysql, postgreSQL etc), this shouldn't be too hard to do.
>

As "a very easy usable and productive computer" is my dream since 15 years,
I have developed a quite
complete theory of how I imagine myself a "very easy usable and productive
computer"

I will use this theory to draw some concrete suggestions (as polite as
possible, nothing
demanding!!!) how I think Mr.Project features could be implemented.

>Yes, a database backend is planned (probably by using libgda which gives
>transparent support for different backends, mysql, postgreSQL and
>possibly others).
>

Some principal thoughts:

XML file format, Database or Data structrue in RAM: For the user it really
doesnt matter.
What counts is how he works with (and with which tools he can manipulate how
effective) the data.

One of the biggest usability problems in current computing interfaces in my
view is the concept of
"SAVE"

Why in the hell a user has to know that there is RAM where the CPU can
manipulate data (and therefore
the user manipulate data), and there is Harddisk, where the user has to
"save" after he manipulated the
data before he will switch down the computer or before the next crash. This
he has to do because
in case of no power supply or crash RAM does loose all data. Only Data on
Harddisk do survive Power loss or crash.

Power loss survivability on harddisk, Data loss in case of Power loss in RAM
and the need to have to be manipulated data im RAM are ***technical
concepts*** no users should need to know about it!!!!!!!!!!!!!!!


Now to the questions of "should we work on the DB" or "should we only store
in the DB"

First: XML is a much more flexible dataformat that storing data in
relational Database.
What I would opt for would be an Object orientated DB (or XML Database with
transactions).
Limiting ourself to relational defined DB strucutre would be (in my point of
view) a mistake for
the expandability/flexibility of Mr.Project.

Second: Aiming at a multiuser, multieditor Project ManagementSoftware, more
that one person would
work on one plan at the same time! Therefore a central Storage of the
current plan would be needed.
This could be done like "the current plan is in my Main memory, and please
send all edits you do on the plan into my main-memory-data structure over
RPC and I will save it from time to time" (==this is obviously not a good
solution!!!)

or it could be done with a central Data-deamon, which keeps track of all
data manipulation of all users and reflects them back to the users when
other user make changes to the data-set (push protocol).
And the data deamon would be responsible for keeping the data save (in case
of power failure), would be able to deliver to the clients other
dataformats, which would be exported over the user interface to be able to
be imported to other programms by the user.
The central data deamon would keep the data save. But how the deamon keeps
the data I really dont care.
There could be user programms or deamons updating from external resources
(like accounting) constantly data in the central-Project-data-repository.

And yes. It might be needed to have a flexible powerfull Interface between
User interface and Data-repository (because SQL with its predefined Tables
and relations is just not powerfull enought).
Because when a new user-feature-module is written, which uses a new data
strucure in RAM, this must
be also be able to be reflected to the data-repository-deamon without the
need of Protocol changes on the
deamon side. How about sending objects to the data-deamon??? or small XML
files?? (I am no trained Object Oriented programmer!)

How about a real XML database? (available as open source project!!)


>What I'm unsure of is that when you work in this mode. Do you want your
>changes to be written back directly (you change something in the UI and
>it's updated on the database directly). Or do you want something like
>"save" or "update database" instead.
>

I prefer the concept of "publish".

"publish" in my view is a strong concept:

Imagine editing a letter: You start typing the letter. (in case of a crash
of the computer, you dont
want to have lost one typo). You dont want others to see the letter while
you edit it. As long as you work on your letter, others dont have to know
about the content of your document. But once you are finished,
you want others to read the letter. You "publish" the letter on the central
document repository.
From this time on, others (who you are allowed to read it) can read the
letter and even can write and answer (and point at your document).
The concept of "publish" means that youself are not able to withdraw, delete
or change the document you
"published" once. This way other can always point at your original document
with the trust that it will not change or

This concept of "publish" would fit also very well into MrProject.

Edit privately the part of the project plan you are responsible for as long
as you want (while seeing
in realtime what changes to the project others did publish (the
central-server is pushing the changes). And when you are done, then
**publish** your changes which you will not be able to delete or change. But
you could publish any time a new update.

Others could look at all your project plans your published over time.

Your Project Management client would be responsible to loose no
data you edit privately in case of power loss or crash.

The central data repository could offer a service for the clients to keep
"the unpublished changes of
individual users" so that they dont have to store the unpublished data
locally when shutting down the computer on the end of the day and next day
continue the work.
When you start your computer in the morning, you would get automatically
loaded an current
situation of the central project plan with all published changes of the
others and your "unpublished edits in progress" you can continue to work on.


>If you want the first, it's harder to implement, if you want the second
>it's a piece of cake.
>

I think my suggestions are much harder to implement then the first.

But the question might not be "what is easy to implement" but much
more "what makes MrProject a killer application to a certain type of users"

And a killerapp is what everyone is searching for.

Just my 0.02 c

Yours

edmund humenberger

>Regards,
>  Mikael Hallendal