re: Mr. Project DB

Thanx for taking your time and listening to me:

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

Might be.

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

I think that some small differences in function sometimes make a big
difference
for users. And I still think that not beeing able to delete something is a
big difference compared to the concept of "Save" so that a new word should
be used, as I think to "publish" is a new concept seen from the user
perspective.
But you are right that seen from the programmers perspective it is quite
similar to "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.
>
>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.
>

You are right here too: I just wanted to make clear where my suggestions
come from.  My general experience with Linux people  (KDE or Gnome) is that
they say: "It is good as it is because it is this way since ever, so it must
be good and therefore we dont need to change it"

Just look at the crap email clients (from a user perspective) the Open
Source
community produced for the last 20 years.
Then there had to be Microsoft to introduce new concepts, and users loved
it,
and open source programmers started to copy the concepts.

But Open Source programmers "very rarely" introduce new user interface
concepts or
make software more easy usable. They just dont get it even when I explain
then
the advantages of new concepts.

>> Now to the questions of "should we work on the DB" or "should we only
sto=
>re
>> 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
wi=
>th
>> 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?
>

Because you can throw an XML file to a XML database and the database doesnt
need to have tables set up for the data. An XML database does not have
predefined
tables and relations for the data (records). When throwing an XML file at a
XML DATABASE,
the strucutre of the Database comes with the XML file.
So when you throw a new scructured XML file at the DB, it just takes it. No
admin interaction is needed.

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

From the technical point of view: yes

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


As every task is owned by a person, only the owner can edit it. So no
collision
can happen as described by you. The person can break a task into subtasks
and make
more detailed plans from a big task it was assigned as beeing responsible
for it and
it accepted beeing responsible for it.

Yu can change ownership (of process) if you have the right to do so.

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

No.

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

I dont think that that kind of features are needed (at least not for the far
future).

>> >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
user=
>s"

Yours

Edmund