NYCPHP Meetup

[Hans Zaunere]

> Still, I'm trying to make a way for the user to have "mostly current"
> data from the central system, and also enter data without waiting for
> each request to be approved.  I have been thinking you could run a local
> copy of the system on the user's laptop, then have some helper program
> in the back that communicates with the central server to send and
> receive data asynchronously, pushing user changes and polling for new
> data from the central server as fast as the Internet connection allows.
> The idea is that, except for a few minutes of latency, the user would
> never know the difference.
> 
> The big problem I'm running into is managing potential data collisions:
> data changes from two or more users that conflict with each other but
> aren't discovered until later because of the latency.  As far as I can
> see this is an application-specific problem -- that is, it's up to the
> developer (me) to make the application smart enough to watch conflicts
> and prevent collisions.

Jumping into this late...

You may want to consider using web services.  Data would be stored in a
local MySQL database, and then as you mention, a central server aggregates
the data from all the locations.

The reason I mention web services, is that HTTP is typically more robust
over flakey connectivity than database protocols are.

The central web service would then hand out data per requests from the
remote offices, if it didn't already exist in the local cache, or it was
determined to be stale.  Using a optimistic type locking scheme and built in
conflict resolution, the central web service would then handle data sent
back from the remote locations.

Each remote location, however, could of course use a local MySQL instance,
and in a fully transactional way.  Then on some event or time basis, data
would be sent back to the central office over HTTP (probably actually
HTTPS).  Depending on the complexity of the data, though, this may be a good
or bad idea.

H