QFilehandle required for client-server text app.

SGaist

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.

stefbon

@SGaist As far as I can see it's not making use of KIO.

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

stefbon

@JonB Well I notice some not knowing how OSNS will work.

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

stefbon

@Nils-Sjoberg said in QFilehandle required for client-server text app.:

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

stefbon

As I have your attention, the QIODevice class offers functionality to access a file (local or remote).
I have to add the functionality to implement use by more than one user, like locking a part of the file,
and notifiying the user about events like someone else started editing the file.

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

Anyway, have a good day,

Stef Bon

SimonSchroeder

I didn't know that only locking part of a file is a thing. Even more so, most office formats are ZIP files, so you cannot just change parts of it. Even with a text file, if you insert text in the middle everything that comes after it has to be moved. File based synchronization for collaborative editing would be really hard to implement. I expect modern software to just communicate directly with each other.

JonB

@stefbon
If you appear to have a "working" fd which does what you want and you then want a QFile wrapper for a Qt program then as I said earlier you could use that QFile::open() overload.

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.

stefbon

@JonB and others

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

stefbon

Last post before I start another topic how to solve this. I think that the classic idea of a file (and a filedescriptor) does not work with collborative editing. I think that a document is not a file anymore, but a group of ordered paragraps. 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.

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

JonB

@stefbon said in QFilehandle required for client-server text app.:

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....

SimonSchroeder

I would say that Microsoft Word has already established what users expect when editing files together: You see all changes happening immediately together with a colored cursor for each user with a tag of their name. And those cursors move around live. The best thing is that you can follow where other users are currently editing the document and you'll most likely avoid editing the same thing.

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.

Emma-2000

This post is deleted!