NetworkRepository

MeatballWiki | RecentChanges | Random Page | Indices | Categories

Questions: Why is the file menu still paper orientated? Why doesn't it have a "Checkout from Repository..." and a "Commit to Repository..."? And why doesn't it have a "Publish to Website..."?

Most of the files I use these days are checked out from repositories, downloaded from websites or made by myself. With use I mean CopyPasteEditPublish (or maybe RipMixBurn: The battle cry of the remix generation). But my tools are not helping me anymore, they are fighting me. For example: I can't use the Finder, because it's not aware of the simple fact that it's moving files around in a working folder. I have changed, and the tools have not evolved with me. I have out grown them. -- FormerContributor?

There are just too many different systems for keeping repositories out there, which all have just a slightly different approach to it. Why is it still imposible to move a file from one repository to another without losing its VersionHistory? Why are they still line orientated? Why not use syntax or maybe even semantics to track change? But for now, first this: Why not integrate the general interface into the File Manager?

To implement a repository-aware file manager we could use the same method as we do for printing: a common interaction protocol and drivers which implement the execution in a device specific manner. We could implement a driver-like system for collaborative editing (e.g CVS, subversion, etc) into the file manager. Naturally the file manager (and any other shell) should be aware of this and use the driver's mkdir, delete, rename, move, revert, etc. when inside a working folder. Other applications should have at least some relevant support for this as well.

We could use the same approach to implement a "Publish to Website..." option in the file menu. Just a driver for the website control system (blog and wiki software) we're using; maybe with the option of leaving in the clipboard the url of the published file. (Isn't "Print..." just a other word for "Publish to Paper..."?)

Most people who talk about collaboration tools are talking about an application, web-based or not; They really don't get it. A collaboration tool must be more than that to be really useful: It should enable peer groups to work together seamless and it should promote CopyPasteEditPublish without having people jump through hoops.

The way in which we will use computers will change. The computer will change from a solid, breakable more or less portable object, into a highly portable personal pad of tab device and for communal use we will develop huge board like devices with wiki-like access control. Note however that this only applies to the computers people will interface with directly; there will still be uses for library like structures which are not very portable: The Network Repository servers will be the libraries of changing documents.

The "file folder" system was based on the MultiVac? view of computer systems as supplementing, rationalizing, and then replacing bureaucracies. But in the DigitalNetwork age, your repository idea makes infinitely more sense, which is why I called this page Network Repository. -- SunirShah

Network Repository is a great name to describe it. It makes me think of the reason why NetworkFileSystems?, never made much sense to me: People are mobile if given the choice and when you're mobile you just can not be connected all of the time. The idea for a Network Repository developed as it fits much better in the reality of a mobile dynamically networked world. -- FormerContributor?

Just found http://scplugin.tigris.org (you will have to build it yourself, the package did not work) which does integrate with the MacOSX? Finder very well and demonstrates my point very nicely. -- FormerContributor?

Today I found [Merlin] (does not seem to be very active any more) and it basically discribes a NetworkObjectRepository? for a OS which does not use files. I've looked at the Wiki:SelfLanguage and I'm very impressed. Maybe I'm all wrong about the above: files could someday be replaced by much beter forms of persistant storage.

At [gnome.org] Seth has a neat article about storage which has a few insights which the solution above would not solve (e.g. with versioning there is the problem of merging which will continue to be a problem in any file (steam) based storage solution). Although he is focusing on Natural Language processing mostly, it's a good read.

Do we really need to store data in flat files? Can't we develop a more richer solution? Where the structure we see is more a view on the data then the way in which the data is stored? To separate user level presentation from software level representation and the lower level below them?

NetworkRepository

Discussion