W3C home > Mailing lists > Public > public-rww@w3.org > January 2017

proposal for PATCH workflows

From: Melvin Carvalho <melvincarvalho@gmail.com>
Date: Mon, 2 Jan 2017 00:34:41 +0100
Message-ID: <CAKaEYhJtTJEQMChROPRPRGn3k89USc5J4PLnetuckGSpQ5Uz6A@mail.gmail.com>
To: public-rww <public-rww@w3.org>
Some ideas from timbl on the possible evolution of the patch workflow
currently used by some systems

https://github.com/solid/solid/blob/master/proposals/patch-directions.md

Reasonable future features for the patch distribution system include:

   - When listening for updates, the client should get a patch instead of a
   ping, and so will be able to apply the patch instead of, as currently,
   reloading the file.
   - Move to an N3 compatible patch format, like <#patch> :where {...},
   :delete {...} etc etc
   - Extend the patch format to allow multiple files to be patched as an
   atomic operation
   - When receiving a stream of updates, the server could cache the graph
   in memory, not reading it again from the file system
   -

   Further the server doesn't write back the patched file every patch, only
   every few seconds.

   Longer term ideas, larger projects:
   -

   When clients of listening to the same resource are in fact located
   physically close, they could exchange patches through other medium like
   wifi or bluetooth.
   - The system can evolve (under stress) to work entirely with distributed
   patches, making the original HTTP server unnecessary
   - The patches could be combined with hashes of versions of folders to be
   the basis for a git-like version control system, or connect to git itself,
   etc
Received on Sunday, 1 January 2017 23:35:16 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 1 January 2017 23:35:17 UTC