OSDev.org

Pype.Clicker wrote: Yes, you certainly wants control... but do you want directories.

Fact is that many metaphors and structures in computing are so widespread that, even when they might not have been the best of all ideas when invented, they are the best solution now because millions of users are familiar with them, thousands of books refer to them, and billions of source code lines have been build around them.

Directories, for example.

I've read many a paper on database-based file systems, "content search" etc. etc. - but nothing has convinced me so far that either a computer newbie or a veteran will actually find that easier to use.

Moreover, aren't more likely to need recovery of e-mail you start typing before you accidently hit ALT+F4 than the recovery of your thesis (which you have on 5 CDs scattered in 3 different physical places) ?

Undo in the e-mail program?

All these aren't really issues of the underlying file structure, but rather issues of the application API - and could be solved by a proper text widget.

...you might wish to keep track of every typed character between two saves, no ? They can be discarded when you hit "SAVE", but should be kept prior that checkpoint.

100% ACK.

Then again, as most things Pro-POS'ish, that idea never got proven. :-\

If it was proved, we'd be using it, not talkin about it

;D

After all, directories aren't that hard to understand, are they? The versioned filesystem thing ... it is insofar hard to create because of the delta information you need to store away for each change of the file. How knows the File system about how to make a correct delta of a c source file? How knows it about not to make a delta for a binary? via attribute node? That's way too complicated.

In my opinion, that's the task for an application. It's best to have some nice middleware (Serena Version Manager f. ex.) take care of the delta & property management for the source files. this way the filesystem can concentrate on usual file system tasks: managing nodes & blocks & keeping transaction journals.

*gg*

Well, I gonna rant more as soon as I've finally managed to implement a file system browser for my OS. Not as if that's gonna happen too soon these days. I'm more busy with running and being outside with my fairy than with OS deving in my spare time *gg*

beyond infinity wrote: The versioned filesystem thing ... it is insofar hard to create because of the delta information you need to store away for each change of the file. How knows the File system about how to make a correct delta of a c source file? How knows it about not to make a delta for a binary?

Via MIME type / magic number / filename extension? The same way it knows that it has to open a source file in a text editor and the spreadsheet in the office suite and the movie in the movie player?

Take a look at numerous developer-related GNU tools. They default to, if a file is not available, checking for a RCS / SCCS version of that file, and perform their activity on that file.

Instead of spreading such functionality across several applications - all of which would have to be updated should the format change or a new versioning architecture be introduced - that could be encapsuled into the file system IMHO.

In my opinion, that's the task for an application. It's best to have some nice middleware (Serena Version Manager f. ex.) take care of the delta & property management for the source files.

Means you have to do checkout / checkin / tagging / branching etc. etc. by hand. That might be OK for a developer type, but it's not OK for my mum.

Quote from: beyond infinity on Today at 10:55:55am
The versioned filesystem thing ... it is insofar hard to create because of the delta information you need to store away for each change of the file. How knows the File system about how to make a correct delta of a c source file? How knows it about not to make a delta for a binary?
--->
Via MIME type / magic number / filename extension? The same way it knows that it has to open a source file in a text editor and the spreadsheet in the office suite and the movie in the movie player?

the file system services shall not know nothing about mime types and sorta. They shall only *deliver* the file I want to have. That's my opinion. I have the slight impression that you mix up something crucial here: The launcher (say explorer.exe in windows f. ex.), which knows about mime types via config file or registry, and the File System Service - which delivers the file (say from ext2 fs, reiserFS, SkyFS ...). Feel free to correct me if I'm in err.

The task you describe oughta be done by some service *above* the file system services. In short some sorta library the application asks ere it opens a file. It doesn't say open file then, it says "check out" file. and upon saving the application says "check in" file. I think I can follow you in sofar as this has to be hidden away from Joe Average or your mum.

Well ... your average PowerBuilder project knows siht about SCCS unless you tell it explicitly to connect the project to it.

BTW which gnu developer tools do you refer to? Any Keywords to google for?

Stay safe

beyond infinity wrote: I have the slight impression that you mix up something crucial here: The launcher (say explorer.exe in windows f. ex.), which knows about mime types via config file or registry, and the File System Service - which delivers the file (say from ext2 fs, reiserFS, SkyFS ...). Feel free to correct me if I'm in err.

I pictured the option "version control" / "no version control" to be a flag set in the properties of the directory, effective for all subdirectories, regardless of underlying file system. To applications the VCS feature should be as transparent as possible, so that e.g. a straight "vi" port would generate a new version on every "save" while being completely ignorant of the fact that past versions are being kept. OS-native apps could, of course, benefit of additional APIs for diff, retrieving old versions and such.

So the VCS is not part of the application, but the OS system. Somewhere.

I agree that the file system handler (translating ReiserFS / ext2fs / VFAT / ... block structures into data streams) is below that version control feature (as this itself shall be independent of file system). But [tt]fopen() / fread()[/tt] are definitely above the optional version control, as that should already be transparent at that point (with additional [tt]RetrievePastVersion()[/tt] etc. provided by the OS API).

So that gives hardware - HW driver - file system driver - VCS (optional) - file access libraries. Definitely below Explorer.exe.

The task you describe oughta be done by some service *above* the file system services. In short some sorta library the application asks ere it opens a file. It doesn't say open file then, it says "check out" file. and upon saving the application says "check in" file.

Resulting in e.g. said "vim" port circumventing the version control feature because it's ignorant of the API. No game.

BTW which gnu developer tools do you refer to? Any Keywords to google for?

GNU 'patch' and 'make', for example. Search their docs for "RCS".

Quote:
The task you describe oughta be done by some service *above* the file system services. In short some sorta library the application asks ere it opens a file. It doesn't say open file then, it says "check out" file. and upon saving the application says "check in" file.

Resulting in e.g. said "vim" port circumventing the version control feature because it's ignorant of the API. No game.

the benefit we os developers have is that we become very good at lying to applications *sfg*

You propose to map fopen to checkout and fclose to checkin (and all the operations between to a buffered verson of the file) - and upon close/checkin the library is to generate a new delta.

With this I can live and so I agree.

For now, my imagination will serve me.

I'm going to make my gui a cross-breed between the GUI and Command line. Right now, I'm developing a RPG engine which will serve as the base for my design (except the Command line part).

Basically, you got a split screen (1/5th to the command line) which is moveable and redizeable (and hideable ;P). Up top you got a virtual stack where there is X layers.

On each layer is a grouping of icons. When you mid-click on a icon, the file is sandboxed and actions are discovered (for example, you can id that a .htm file can be edited by firefox, mozilla, dreamweaver, etc. as well as be opened by .... for viewing). Each layer repersents a "set" or catagory which the user defines. The gui then sets out and finds all of the files related to the terms stated by the user (ex. layer 3: music {*.mp3 *.mid *.ogg *.wav !demo !startup !shutdown ...} : open). First field is "layer" and states we're working with layer X. "3" is the layer id. anything between { and } are defines, filters and rules (it's obvious what *.mp3 does. but !demo could repersent nothing containing "demo"). finally a default action is assigned ": open". All this would be done with a nice gui app which does all the work. For simplicity, there would be "specialty" layers which relate DIRECTLY to files and services, etc. (eg. devices "@hda1" and services "httpd.php@apache").

layers, being a abstract 3D method, could possibly "walked through" as if they were a "space".

When a program is exacuted, a new layer is created for it and auto-tabed to. Each programs private layer is COMPLETELY independant of all others except "global" services (think of a city sewage pipe that goes to every house) like some abstract "clipboard" etc.

One layer would be dedicated to "recent(s)". It would hold: recent files, programs, etc. on "sub-layers" (think of MDI in windows).

Back to the command line: it also would be layered allowing the user to monitor many tasks all at once.

My personal challenge is to not be like Xwindow and have a multi-hundred meg footprint, but rather a 64MB max ;D

Cheers, DH.

hi,
This is a concept for a cool GUI that I made in flash. It has a floating bar down the bottom, where you access the main menu and the drives and settings. Applications could then be accessed from the dropdown bar at the top. If an app was maximised, then it would be above the bottom bar, and you could show it by moving the mouse down to the bottom of the screen.

http://sos.osdcom.info/content.php?content.1

- Stephen