Le jeudi 22 septembre 2005 à 19:06 +0100, Alexandro Colorado a écrit : > On Thu, 22 Sep 2005 13:27:25 +0100, Nicolas Mailhot > <[EMAIL PROTECTED]> wrote: > > > > > On Thu, September 22, 2005 13:34, Alexandro Colorado wrote: > >> I dunno about MS I dont have their suite, however I know it would be > >> achievable to solve a lot of companies issues and promote the use of > >> Master documents. > > > > Master documents, zip, etc are only a workaround. > > It seems you don't know what a master document is, since having 2 files > together are not the same as having sections of files within each other.
I understand perfectly well what a master document is. What I pointed out is 90% of the users will only use it as a oo.o-based zip. Sure integrating stuff all over the place is cool. But integrated stuff is more difficult to manage and in the end of the day users care more about easy to manage than coolness. > > Stuffing everything in a single file does not make its lifecycle more > > manageable, it's just less files to attach to e-mail messages. And it > > creates problems because when you comingle everything the responsability > > boundaries blur. > > Didn't got that at all, you say that the only benefit is because you will > attach less files on your email?? I would like to think you were ironic > there. I was cynical see above. > > Office workers should learn from Developpers which _have_ been doing > > collaborative work for a long time. Any serious software project is > > composed of hundreds/thousands of files created and updated by different > > persons/organisations in parallel and somehow still put together to > > create > > something. (and when I say files it's source code but also ressources > > like > > images, sound files and so on). > > Well thats the concept of dependancy of files, Master documents can > imports part of the 'code' of one file and use it for another file. > > > You want to improve oo.o collaborative capacities ? > > > > 1. add a view where you can manage the set of files that constitute your > > project. It can be a master/compound document or just a filesystem view. > > And the filesystem view is probably better because the components are > > clearly defined. > > We already have this on the navigation for the Master document. Like I wrote, the Master document can be part of the solution. > > 2. create plug-ins to communicate with the various backing stores you > > have > > on the market (Notes databases for enterprise users, subversion/cvs for > > centralised teams, svk/git/darcs for decentralised and/or serverless > > teams). So revisions can be pushed/pulled from the SCM > > We already have conectivity with mysql, postgresql, etc. If you talking > about actual document management then you can get this from SVN or CSV'ng > your company. I'm talking about actual collaborative document management not about database management. And of course you can use SVN or CVS with oo.o files but what's needed is an in-OO.o interface to push/pull document revision from SVN CVS and friends. Because your average user won't touch them with a ten foot pole even if he needs what they do. Hell even your average developer does not interact directly with them but uses the interface its IDE provides. > > 3. modify OO.o so revisions are stored as different files in the SCM not > > in a single OO.o file > > > > And that's about it. No need to reinvent the wheel (badly). Most of the > > infrastructure already exists today, you only have to plug OO.o into it. > > > > We are not reinventing anything here, we are just enhacing the feature so > it talks to other components from the same program. And I wrote the vast majority of users cares more about this program talking to some sort of document store than being able to mix and match local documents. So much in fact that the main use of your master document if it catches on will be used as a poor-man document store that can be mailed to collaborators, not a way to create uber documents. It's absolutely no use to contemplate wondrous document constructions if you don't solve the distribution problem of the bricks (separate documents) you need. Even if users were interested in wondrous document constructions in the first place (MS Works market failure seems to indicate they aren't). -- Nicolas Mailhot
