This usually requires for your documents to live in a "cloud" (even if the cloud is your own private cloud at home) and a server that at least tracks all concurrent users of the document and tells each user about the others.

The best example of what it should have been like is Google Wave (unfortunately, this project has been shut down after only a few years). It was based on XMPP for realtime communication.

Every paragrap has it's own record in a database, so it's easy to achieve the desired locking: everyone can edit (=write to ) a paragraph, unless someone else is already doing that. And inserting, changing and deleting a paragraph is easy to maintain by a server.

It's not going to be as simple as that in your real-world situation.

You are describing pessimistic locking. You are going to require each user to do something before they can edit or delete a paragraph to "lock" it. What are you going to do if the locker then goes to lunch, or never returns? Having a pessimistic lock held for a long time is a pita.

Alternative is optimistic locking. No "blocking" lock held. You save state of paragraph when user starts to edit. When ready to submit changes you make it UPDATE ... SET paragraph = new_paragraph WHERE paragraph = old_paragraph. This ensures update is committed only when nobody else has changed paragraph while you were editing. Often better for sharing. But you still have to deal with what to do if someone else has changed it while you were editing. Usual is to throw away new change and make user redo from newly changed paragraph state. Not so bad for "little records", not so good for "paragraphs".

Then you have inserts. Between two existing paragraphs you & I each decide we want to insert our own new paragraph. There is nothing to lock or compare. Which order do you place these two paragraphs after we each submit? Perhaps "first (based on submit time) submitter's paragraph is inserted and then second submitter's paragraph is inserted after first one" (or other way round). But maybe first inserter's paragraph has to go before the old paragraph after it and second inserter's paragraph has to go after the old paragraph which was before it. they are now the wrong way round.

And a whole host of other similars. It's one thing handling contention on small rows/columns, it's another on documents. Not to mention stuff like your interface may have to "push" changes from one user into another user's session while they are middle of doing something/their own editing. I foresee many problems....

So internally a document is not a file anymore, but a group of ordered paragraphs.
A paragraph is a piece of text, but also an image, an inserted piece of another langauge (R for example).

To have a file you need a goord export function (to ODT and PDF).,

Stef

you are absolutely right. When inserting text in a normal file the synchronisation is a challenge.
I have to think that over. Every user has it's own window to a document. And synchronisation is only required when another user's window "reaches" the text you've inserted/changed.

Lot's of work.

Thanks,

Stef Bon
the Netherlands

File byte range locking is only of use in a database-type file which is accessed directly from clients, not client-server with a central server.

I am not aware of any means of seeing an "event" like someone else "starting to edit the file", however you might define that. The closest is Qt's QFileSystemWatcher Class, but it doesn't achieve that.

Most important is: any solution involving Qt classes the way you want would only at best work if everyone goes through Qt/your code. Assuming you want to allow for non-Qt access from other programs you would need to work at the fd level. Qt does not do anything in QFile etc. which you could not do yourself. And any approach is liable to be platform-dependent and depend on what low-level facilities each platform offers.

And I need a class for users to browse the exported/shared directories.

Anyway, have a good day,

Stef Bon

QFileDevice

Thanks a lot. This looks exactly what I'm looking for. At first I missed the offset in read and write functions, but the seek function will give the desired functionality.

Thanks again,

Stef Bon

OSNS will contact the remote documents server (which is a SSH subsystem), and gets a SSH channel. This is mapped to a local fd. So the applicartion will use an fd (behind the scenes) .

So:

local client fd <-> ssh channel < --- (ssh transport) ---> ssh channel ->ssh subsystem (OSNS documentserver) -> fd to document on remote server

How the remote side handles it's side it;s up to the remote server.

Stef Bon
the Netherlands

But that said, I want to create a set of tools offering an unified interface to network services.
At this moment there are too many different ones. I name some:

• KDE use KIO as you mention
• GNOME use GFS
• VLC uses it's own implementation
• LibreOffice uses it's own implementation

My software OSNS is an attempt to replace them all (and offering one interface). It's very ambitious, I know.

Stef Bon
the Netherlands

Since Calligra is part of KDE, you should check whether it already makes use of KIO. If not, then you should rather go this route as it provides everything you need for what you want to achieve.

which makes use of a fd to a remote document

If you are saying you have been given a fd which does whatever you want remotely, be aware that you can "connect" it to a QFile via bool QFile::open(int fd, QIODeviceBase::OpenMode mode, QFileDevice::FileHandleFlags handleFlags = DontCloseHandle).

If not you have to write your own functionality like @Nils-Sjoberg said.