[ale] Two offices, one data pool

[Ron Frazier]

Hi Michael T.,

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.

Ron

On 02/17/2011 10:13 AM, Michael B. Trausch wrote:
> On Thu, 2011-02-17 at 07:40 -0500, Jim Kinney wrote:
>    
>> put the data source where both offices have crappy access speed.
>>      
> 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.
>
>    
>> 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.
>>      
> 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?
>
>    
>> You _could_ set up a subversion repo and scripts to merge xml
>> docs ....
>>      
> 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
>    
>
>
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
>    

-- 

(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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.ale.org/pipermail/ale/attachments/20110217/c6163c2f/attachment.html