Just can't get enough of that Moose!

[Michael David WINIKOFF]

> > 
> > Yes but I feel it can be encapsulated into a small module.
> 
> Agreed. Lets call it nucleus ;-)

Good name.

> > > =>Next question: Do we have some notion of transactions, atomicity etc.
> > > =>(a 'la database systems)
> > >    Not in the kernel, I think (unless we want exactly-once IPC semantics)
> > > but we should be able to add them later.
> 
> Isn't it possible to create, for example, a transaction object which could be used
> as an environment in which communication can took place safely? But I see the problem
> when the kernel isn't safe at all.

I was thinking of file operations -- I suppose it applies though to any applic
that operates on a number of objects.

TRansaction support to me means that if an application begins operating
on a number of files/objects then
(1) If the application fails midway then it's changes are undone
(2) Other applications attempting to use the same objects are handled in some
	way (Eg. told the objects are locked, given old information)

IN the context of files implementing this type of stuff is usually done using 
logs -- any operation is logged with enough information to undo it.
(Or redo it in the case that a transaction completes but it's changes are still
in memory and the system crashes)

This shouldn't be too hard to add to the file system seeing as it'll be 
replaceable but will involve a fair amount of work.

I feel that providing industrial strength recovery isn't really neccessary.
Some form of file/object locking is needed though.



--------------------------------------------------------------------------------
Michael Winikoff
winikoff@cs.mu.oz.au
Computer science honours. University of Melbourne, Australia.