[ale] Two offices, one data pool

[Michael B. Trausch]

On Thu, 2011-02-17 at 14:24 -0500, Ron Frazier wrote:
> * Perhaps there is a way to get your wish to get your wish of itty bitty 
> level edits.  But, it would probably require a difficult transitional 
> process.  Would it be possible to put the most commonly used documents, 
> not necessarily spreadsheets, into an SQL database?  Each sentence, or 
> each paragraph, or each page could be a record.  Different people could 
> edit those little components at the same time.  It could take the 
> structure of a linked list.  A reporting module could provide access to 
> the "document" as one  contiguous presentation, with the latest 
> committed changes.  You could have version tracking and the ability to 
> revert to historical versions.  The reporting module could also build 
> pdf files or word documents for publishing to other areas, etc.

If there were something like OpenOffice.org, but hosted as a Web
application and without the usual types of lossy translations that are
associated with such things, that would really be absolutely ideal.
Just another Web application.

Some time ago there was an article on Ars about how offices should be
using things like wikis to replace word processors.  For the most part,
I completely agree; the age of the word processor was long ago, when we
prepared reports and documents *to* *be* *printed* and then handed to
someone.  Back in the age of the intraoffice courier who got to
distribute all those stupid little memorandums.  Back when SneakerNet™
was both faster and more reliable than TCP over IP---or was the only
network protocol in existence.

Wikis are very useful for retaining not only documents, but their
history.  Various plugins can be used to generate PDF content (or even
something that can be input into a word processor for formatting to
print) from wiki systems, and in a worst-case situation one can just
type wiki formatting into a text editor and upload it later.  And,
unlike the default settings of most "productivity suites" (egads, I
bloody HATE that term), history is actually retained.  Along with better
accountability for changes, which is most excellent to have, as well.

> * The publishing industry has GOT to have something like this for 
> collaborative writing.

Collaborative writing is best done in plain text if there is a group of
people working on it.  It doesn't matter *what* the plain text is
processed through to get a result.  Some people use wikis, some people
use LaTeX, some people who write books that the likes of me are unable
to read due to being not well-enough equipped in the knowledge-of-math
department use plain TeX.

> * Perhaps a CMS, like Drupal could be used for something like this, or 
> some wiki software.

Indeed.  :)  Fat chance in reality.  I get to implement things with a
hefty list of nonnegotible requirements, more often than not.  Some
days, it's very fun.  Others... well, yeah.

> * Wasn't Google Wave (now deprecated) supposed to allow simultaneous 
> team editing?

I haven't played with the software for it yet, but I _completely_ plan
on hosting a federated wave server at some point.  Or something like it.
I really liked the idea, and while I didn't use it _terribly_
frequently, I used it frequently enough to collaborate with people
hundreds of miles away and absolutely *loved* it.

> * Someone mentioned that Subversion might be helpful.  GIT is another 
> popular system for version control.  http://git-scm.com/

Ew.

I like simple tools that stay out of the way.  Meaning that for DVCS, I
use bzr.  ;-)

That said, version control is something that end-users (true end-users)
should never see.  It just makes their head spin.

> * I don't know how much control you have over the data pipe to the 
> remote site, but, in the historical case I mentioned, I was able to 
> reduce the data traffic on the leased line by about 80% by enabling 
> selective filters on the gateways.  That way, I got much better use out 
> of the pipe.  You might want to consider on the fly data compression on 
> the endpoints, if not already active.  Regardless, 384 Kbps is REALLY 
> restrictive.

I have 100% control over any tunnel that is established.  It's the rest
of the connection that is going to make the tunnel suffer---horribly.

> * Could you bring more bandwidth on line in parallel by using something 
> like 3G / 4G wireless broadband from a cellular company, or something 
> like CLEAR, etc?

It's a possibility---have two, single-IP Internet connections on each
end that are dedicated to the purpose of linking the offices together.
However, that buys very little for the addition of as much complexity as
it would be.

Honestly, my ideal setup would be to have a LAN in the local office, a
LAN in the remote office, and at least a 6 Mbps dedicated link between
the two that could act as either a bridge between the two networks or as
a router between the two networks.  At least that way if there is some
sort of problem where the Internet connection at one end or the other
went down, it'd be possible to route the Internet-bound packets out
through the other side.  It might be slow as all hell... but it'd be a
lot more robust.

I think that ultimately, some way to get them to completely move to an
Internet-centric workflow would be best.  Something where quite
literally all they have to do is on the Web.  That way the only reason
Samba has to stick around at all is to enforce restrictions on the
workstation systems and keep tabs on the authentication stuff that is
running the show.

Of course, that's a problem, too.  Even off-network infrastructure
should use the same credentials.  Single sign on is still a big priority
for them (hell, who _isn't_ it a priority for), and yet not quite there
because of all the pain of integration for things that just don't
support working that way.

	--- Mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://mail.ale.org/pipermail/ale/attachments/20110217/9ff79707/attachment.bin