<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
Hi Michael T.,<br>
<br>
This may be a stupid question, but, if you establish a VPN, couldn't
the remote office directly access the same database as the home base,
with all the normal locking mechanisms, etc. I dealt with a situation
like that once while working with Delta Air Lines. We had a remote
office with a (very slow) leased line and network bridges (more
accurately gateways) at each end of the connection. The remote site
connected directly to a Clipper database just as though they were
sitting at headquarters. All the locking stuff worked fine. They
could also access shared word processing documents, etc. just like they
were at headquarters. I had to spend a whole day once tweaking the
gateway not to forward superfluous traffic to the remote site because
performance was abysmal. Also, I had to store a local copy of my
Clipper database app and load it from the local hard drive at the
remote site rather than retrieving it over the leased line when someone
started it. I did similar things with the executables for common
office applications. So, the remote site started up executables
locally, but accessed data files from the file share at headquarters.
It never did work great, but it was acceptable. With a VPN, I was
thinking you could do something similar, as the VPN would act like a
bridge. That would eliminate your concurrency problems. Maybe
something like Himachi might work. Just a thought.<br>
<br>
Ron<br>
<br>
On 02/17/2011 10:13 AM, Michael B. Trausch wrote:
<blockquote cite="mid:1297955623.3736.17.camel@aloe" type="cite">
<pre wrap="">On Thu, 2011-02-17 at 07:40 -0500, Jim Kinney wrote:
</pre>
<blockquote type="cite">
<pre wrap="">put the data source where both offices have crappy access speed.
</pre>
</blockquote>
<pre wrap="">
Well, I had thought about putting something together, but I don't know
how well it'd do.
What I've been thinking about is some method by which the existing Samba
infrastructure could be used in order to ensure that both sides have
locks and such which are shared between them. For example, if all of
the data is stored on Amazon's S3 service, and then a VFS plugin was
written for Samba that would provide access to the data stored on S3 as
a shared filesystem, I thought it might be possible to use the whole
thing in a way so as to keep the requirement that two people should not
be able to attempt to modify the document at once.
For the moment, everything's in one office. So if someone opens a
spreadsheet, and then someone else opens the same spreadsheet, the
second user gets the spreadsheet in read-only mode, because the first
person has it open and protected against writes by other people.
The other bonus would be that if it's done using Samba's VFS support, it
would look like it would be possible to support the whole Windows way of
doing things with relative ease. Security descriptors and all that jazz
could be stored as metadata attached to the files, as well as things
like file locks.
The only other problem that would need to be solved would be that of
caching; documents that are frequently accessed should be cached locally
so that round-trips to the Internet can be deferred to an extent. A
method for invalidating the cache would also be required; if document X
is in the local cache in office A, and someone in office B modifies the
document, there should be some way for the server in office A to become
aware of that fact and invalidate its copy of it (either fetching the
updated copy and inserting that into its cache, or just dropping it
entirely).
I'd (briefly) considered something like DRBD, but I just can't see that
being functional enough without a leased line being used to make things
work well. I've no interest in attempting to resolve issues like the
offices falling out of sync with each other. It has to be stupid-easy
for people to use, and stupid-easy for me to manage. That's really the
goal.
</pre>
<blockquote type="cite">
<pre wrap="">Given the desktop clients they will be using most likely M$office. So
"shared data" means word files. To prevent clashes you need a document
management tool. Knowlegetree is one. Alfresco is another.
</pre>
</blockquote>
<pre wrap="">
I will look into both of those. Do those types of systems have some
sort of method by which Samba could expose their repositories as shared
filesystems?
</pre>
<blockquote type="cite">
<pre wrap="">You _could_ set up a subversion repo and scripts to merge xml
docs ....
</pre>
</blockquote>
<pre wrap="">
Eeeeeeee, no. bzr, maybe. :-P
But they're not all XML documents, anyway. There is an awful lot of
legacy binary blob document types, and even the newer XML using ones are
wrapped up in binary files such that automatic merging would become
problematic, I think. One would have to have some sort of method for
really deeply inspecting the document(s) and finding out how to easily
diff them and all their content with the previous version. Given the
number of Office 2003 and earlier versions of documents that are
present, that would be challenging at best.
--- Mike
</pre>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
Ale mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Ale@ale.org">Ale@ale.org</a>
<a class="moz-txt-link-freetext" href="http://mail.ale.org/mailman/listinfo/ale">http://mail.ale.org/mailman/listinfo/ale</a>
See JOBS, ANNOUNCE and SCHOOLS lists at
<a class="moz-txt-link-freetext" href="http://mail.ale.org/mailman/listinfo">http://mail.ale.org/mailman/listinfo</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
(PS - If you email me and don't get a quick response, you might want to
call on the phone. I get about 300 emails per day from alternate energy
mailing lists and such. I don't always see new messages very quickly.)
Ron Frazier
770-205-9422 (O) Leave a message.
linuxdude AT c3energy.com
</pre>
</body>
</html>