On Thu, 22 Sep 2005 23:58:11 +0100, Nicolas Mailhot
<[EMAIL PROTECTED]> wrote:
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.
Then again thats the business gap (opportunity) that openoffice.org gives
to solution providers. Connecting the front end with the back end. And is
not like we are just discovering, there are many people that have
developed this systems already.
You might want to check out this presentaiton from OOoCon 2005:
http://marketing.openoffice.org/ooocon2004/presentations/friday/developerplatform.pdf
Some diagrams reflect the feeling of having this carry out in corporations
which usually will pay top dollars to have it implemented.
Of course you can also just hire some developers and come with your own
solution based on OpenOffice.org and also give it as open source.
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).
--
Alexandro Colorado
CoLeader of OpenOffice.org ES
http://es.openoffice.org
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
