8,288
edits
Changes
Jump to navigation
Jump to search
Line 1:
Line 1: + Line 63:
Line 64: + + + + + + + + + + + +
no edit summary
<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.
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.
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 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]]