https://bugs.documentfoundation.org/show_bug.cgi?id=103450
Bug ID: 103450
Summary: Implement (and extend) WOPI postMessage API
Product: LibreOffice Online
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: LibreOffice
Assignee: [email protected]
Reporter: [email protected]
The API is described at
https://wopi.readthedocs.io/en/latest/scenarios/postmessage.html#postmessage
For start we don't really need a full implementation with all documented
messages, but we should have the basics and format.
On the other hand, for our use-case I propose to implement some additional API.
1. Editor Initialization
------------------------
It would be a "ready" event triggered by the editor when it finished
loading. We would use it for two things: 1) stop displaying "Loading..."
message (not as important), 2) we would know when we can start using
postMessage API commands. This is defined as Host_PostmessageReady and
App_LoadingStatus in WOPI API.
2. Document session members management.
---------------------------------------
In Kolab we have a concept of "session owner". This is a user that
created the session and is able to invite/add other users to this
session. Users can also ask him for permission to join this session.
It's like a chat room with access administration.
For the same document we can technically have many ongoing sessions
(created by different users).
So, we have a "plus" button that is used by the owner to invite new session
members (collaborators, invitees, name them as you want). On the left of the
button, users will see pictures of all members that already joined the
session (and have the editor open). There will be at least one picture
of the current user.
>From WOPI API we already have OwnerId and UserId. So, the "session
owner" concept can be implemented.
To implement these I need the following postMessage API:
2.1. "getMembers" - returns all users in the session (including current
user). Usually will be called immediately after the editor is loaded.
Expected return value is an array of objects with following properties:
- memberId: unique member identifier in the session. Note that it
should take into account a situation where the same user opens more than
one browser window for the same document/session.
- fullName: e.g. user first and last name
- email: this actually is used by us as a user identifier in the system.
- color: to distinguish modifications/annotations inserted by
specified user. We use the color for a border of the user picture
described above. WebODF used this color for cursor/selection/annotations
done by specified user. Color is specified in css color format.
2.2. "memberAdded" - event executed when a new user joins the editing
session. We use this to add user picture to the list of session
members in our toolbar. Expected return value is the object with props
described in 2.1.
2.3. "memberRemoved" - as above but when a member closes his editor
window. Expected return value is an object with at least memberId
property set. We need it to remove the user picture from the members list.
2.4. "sessionClosed" - event triggered when an editing session owner
terminates the session (using the Terminate button in the toolbar). Only
the owner can do this. In this case we inform all session members and
close their browser windows, as the "meeting" is over and they can't
continue editing.
Notes:
- The color and memberId would need to be set by CODE, both are
values unique to the session. For first version we could skip color.
- WOPI already defines UserFriendlyName, that should be used here.
- We already use email addresses as WOPI UserId, so there's no need
to invent new property.
- Property names could be changed to something different, we can use
these from WOPI.
- An idea for later: As I see in CODE only one user can edit the
document at a time, right? If we can't get rid of this limitation, we
could probably implement additional property "isEditor" with additional
"editorChange" event, to give users an indication who's current editor
in the session, e.g. by additional bullet-icon on the user picture.
--
You are receiving this mail because:
You are the assignee for the bug._______________________________________________
Libreoffice-bugs mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
