WebCollab: Difference between revisions

(2 intermediate revisions by 2 users not shown)

Line 1:

<noinclude>{{GoogleTrans-en}}{{TOCright}}</noinclude>

Activities in Sugar may employ the Telepathy framework to implement collaborative behaviors over the network. The messages sent between participating Activities may be routed through a server, when using Telepathy's XMPP backend (Gabble), or they may be routed directly from the sender to the receiver, when using Telepathy's Link-local XMPP backend (Salut). Communication with Telepathy occurs over D-Bus, using the Telepathy D-Bus API.

Line 63:

Line 64:

The large amount of polling required here represents a potential decrease in efficiency. To achieve high efficiency, the client must employ a form of "long polling" or similar push-like technique. It is not clear whether such behavior can work with a typical unmodified WebDAV server.

===The Type-1 SugarHTTPCollab Server->Server Interface===

This interface is the same as the Type-0, updated to include directories and optionally locking.

JSCollab does not require any concurrency control, so locking is only relevant if it is implemented in a fashion that is at least somewhat secure against a malicious client. One obvious way to do this is for anyone who locks a path to issue a message indicating "I know the secret token for this lock". If any other server receives a request to modify or unlock a locked path, it must (privately*) forward the token from the request to the server that knows the token. If the token is correct, that server will issue a broadcast message, "X knows the secret token for the lock"; otherwise it will privately respond "no". The broadcast message forms a chain of trust from the creator of the lock, indicating who knows the token. Servers must reject requests to delete, modify, or unlock a file from a server that has not been identified as knowing the token.

This does not resolve concurrency issues, but it does prevent a malicious user from deleting locked files without knowledge of the secret token.

*: If private transmissions are not available, the system could instead transmit a cryptographic hash of the concatenation of the token and the sender's Telepathy identifier, which can easily be verified by the server, but cannot be reused.

[[Category:Idea]]

[[Category:Collaboration]]

@@ Line 1: / Line 1: @@
+<noinclude>{{GoogleTrans-en}}{{TOCright}}</noinclude>
 Activities in Sugar may employ the Telepathy framework to implement collaborative behaviors over the network.  The messages sent between participating Activities may be routed through a server, when using Telepathy's XMPP backend (Gabble), or they may be routed directly from the sender to the receiver, when using Telepathy's Link-local XMPP backend (Salut).  Communication with Telepathy occurs over D-Bus, using the Telepathy D-Bus API.
@@ Line 63: / Line 64: @@
 The large amount of polling required here represents a potential decrease in efficiency.  To achieve high efficiency, the client must employ a form of "long polling" or similar push-like technique.  It is not clear whether such behavior can work with a typical unmodified WebDAV server.
+===The Type-1 SugarHTTPCollab Server->Server Interface===
+This interface is the same as the Type-0, updated to include directories and optionally locking.
+JSCollab does not require any concurrency control, so locking is only relevant if it is implemented in a fashion that is at least somewhat secure against a malicious client.  One obvious way to do this is for anyone who locks a path to issue a message indicating "I know the secret token for this lock".  If any other server receives a request to modify or unlock a locked path, it must (privately*) forward the token from the request to the server that knows the token.  If the token is correct, that server will issue a broadcast message, "X knows the secret token for the lock"; otherwise it will privately respond "no".  The broadcast message forms a chain of trust from the creator of the lock, indicating who knows the token.  Servers must reject requests to delete, modify, or unlock a file from a server that has not been identified as knowing the token.
+This does not resolve concurrency issues, but it does prevent a malicious user from deleting locked files without knowledge of the secret token.
+*: If private transmissions are not available, the system could instead transmit a cryptographic hash of the concatenation of the token and the sender's Telepathy identifier, which can easily be verified by the server, but cannot be reused.
+[[Category:Idea]]
+[[Category:Collaboration]]