Re: Mr. Project DB

sön 2002-08-25 klockan 12.59 skrev info:

First of all, thanks for the input. Second, I think you are getting down
to implementation details which imho isn't really relevant yet. 

What I'm currently curious about is how to get the multiuser UI useful
and behaving like one would suspect. If you call the feature of
committing to the repo/database/server save, publish, commit, ..., isn't
really relevant here either (though you explained a few difference
between traditional save and publish it's basically the same).

> 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.

This is not a discussion to be held in the MrProject project. This
should be discussed in a mailing list at GNOME or KDE or any other
desktop environment. Because basically, MrProject should behave in the
same way as other GNOME (GNOME Office) applications.

> 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.

Hmm .. not sure I get what you mean here? Why would an XML file be more
flexible than a relational database?

> >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".

Which is pretty much like saving in a public place and keeping each save
file. Anyway, it doesn't solve the issue that you have by having live
data in your client (which you would get with a push protocol from the
server), imagine the following scenario:

Both person A and person B opens the project on there computers. It just
so happens that both person A and person B tries to edit the same task
at the same time. Person A finishing his changes before person B does
and commit his data to the server, which in turn pushes the changes to
person B. Person B would now (while still editing the task) get all of
person A's changes updating his local copy. He will be very confused and
he probably didn't want this.

So, how can it be solved. Maybe in some way similar to how CVS works:

When you want to commit you check for changes in the repository
(server), if there are changes you have to update your local copy first.
This makes sure that all conflicts are handled on the client side. If a
conflict arises the user must resolve it before committing. 

This might be a good idea, but it will probably add a bunch of UI
issues, like how to resolve conflicts in a good and easy-to-understand
way. How should it be visualized and so on. I prefer to leave most of
these thoughts to the future until after we have decided what might be
the best way to go here.

> >If you want the first, it's harder to implement, if you want the second
> >it's a piece of cake.
> 
> 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"

It never was. It was just an explanation on what would be easier to
implement. 

Regards,
  Mikael Hallendal

-- 
Mikael Hallendal                [email protected]
CodeFactory AB                  http://www.codefactory.se/
Office: +46 (0)8 587 583 05     Cell: +46 (0)709 718 918