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. Mark _______________________________________________ fossil-users mailing list firstname.lastname@example.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users