On 12/06/15 20:05, Ron W wrote:
> On Fri, Jun 12, 2015 at 2:15 PM, Mark <fos...@happybeing.com> wrote:
>>  no way for remote devices to communicate
>> with a server on another client over HTTP (because this would defeat the
>> security of the network).
> So SAFE Network does support applications that use TCP ?
SAFE uses various underlying protocols (not my area but) but
communication between clients should ideally be completely anonymous (no
knowledge of destination IP address for example).

> Fossil's sync protocol "piggy backs" on HTTP, but really is just a
> bidirectional byte stream.. In theory, any communication service that
> supports byte streams (like TCP) could be used.
I don't know, but expect byte streams could be used if p2p sharing was
appropriate, but I'm not sure it would be - see below.

>> It might be feasible to re-route client-server HTTP interactions over
>> SAFE messaging, but this would require one client act as a hub which is
>> again breaking the raison d'etre of SAFE (decentralisation).
> Fossil can be used in a purely peer-to-peer arrangement.
In this case, the issue would be needed both peers available
concurrently, which is unrealistic given that no-one wants to take the
role of (high availablity) server.

The network acts somewhat like a server - constant availability for
routing and storage - but cannot host a Fossil server itself, so this
would have to sit on a client which as I say may not be around when
someone wants to push/pull/clone.

So my thought was that each client can have both its own local repo, and
be running a Fossil server which is managing a separate "master" repo
that is also managed by other servers on other clients.
>> 1) something like a shared disk, containing a shared fossil repo, which
>> the server on each client can push/pull/clone. SAFE Network supports
>> mounting of storage as a virtual drive for example, and sharing would
>> allow multiple clients to access a shared storage area in this way.
>> I'm thinking it's unlikely that Fossil caters for multiple servers
>> talking to a shared repo file, but if it does, let me kiss your hand! I
>> think this would just work out of the box
> (Saw Richard's reply as I was writing this)
> Yes, as Richard said, a single repo file can be accessed by multiple
> instances of Fossil.
> I would still recommend that each "work station" have a local repo that
> gets sync'd to the shared repo. The way I did it requires local TCP, but
> the help page for "fossil clone" shows a "file:"URL format, suggesting it
> might be possible to sync with out needing TCP.
> (http://fossil-scm.org/index.html/help?cmd=clone)

If we can handle file locking as Richard suggests in his reply, I don't
think we need TCP etc.

For example.

Two client machines 1 & 2, each with a local repo, and each running a
Fossil server. Both servers are configured to access a single master
repo file that sits on a shared disk, mounted on both machine 1 and
machine 2.

User A on machine 1 can do everything with the Fossil command line (as I
understand it). He clones from his local Fossil server passing and HTTP
URL to address the server, the server accesses the shared repo on the
filesystem, and responds to the HTTP request which delivers a cloned
copy to create a local repo on machine 1.

User A makes changes and commits using the command line. With autosync,
I think the server is notified and automatically updates the shared
master repo (mounted on the filesystem).

If I've understood, all we need is to ensure the file locking works
between the servers on machines 1 & 2 (and 3, 4, 5 ...) when accessing
the shared master repo. To determine this I need to understand how
Fossil does this, and to see what SAFE can support when shared storage
is mounted as a virtual drive.

Thanks for your help! I'm excited at the possibility of having this
facility available on SAFE network early on.

fossil-users mailing list

Reply via email to