Asynchronous, Bi-Directional ONC-RPC: status + input requested

[Derek Atkins]

David Merrill <dmerrill@lupercalia.net> writes:

> You were clear; I'm asking a slightly different question.

Ok....

> I am not convinced that keeping clients up to date is necessary. I am
> thinking of a paradigm just like a web interface to the engine, and you
> get new data by hitting refresh. If you really need new data, you can
> get it whenever you want it.

This can be a hell of a lot of data.  If you haven't noticed, a data
refresh requires downloading ALL your data ALL the time (well, every
time you refresh).  Perhaps if you only have one transaction open this
isn't a big deal, except now you're downloading that transaction over
and over for potentially no reason at all.  It also means you now have
to go poll the server for changes, and Polling is Bad (TM).

> Tell me what practical problems this would pose for the user and/or
> the system. Increased network traffic? I'm not sure about that,
> because many, many users would never bother to refresh. Most real
> installations would have a single person accessing any given account
> at a time, and probably one person, period, with access to the data.
> Write access, anyway.

As I said, network traffic is an issue.  And users would HAVE to
refresh before they can commit.  The problem gets worse if you
actually do have multiple users writing data.

I can EASILY envision two people with write access: me and my wife.  I
can also easily envision both of us using it at the same time.  I
certainly can't guarantee that we wouldn't want to edit the same
account at the same time.

> It seems that you're designing a system to handle 100 clerks sitting
> at terminals typing away, and I don't think that's realistic. It
> certainly makes the system far more powerful and scaleable - I just
> think you're adding lots of complexity for little real-world gain.

No, I'm designing the system for TWO "clerks" sitting at terminals
typing away.  It just so happens that it will also scale to 100. ;) If
I wanted purely read-only (update-via-refresh) semantics, I'd build a
pure CGI interface and use Netscape as my client.  But that's not what
I want.  I want live data in a distributed system.  Perhaps I'm
over-engineering it a bit, but I like having live data.

> If you haven't noticed by now, I am very much a minimalist. Get the
> job done as simply as possible. And no simpler. :-)

And if you haven't noticed, I like designing for the long-haul, making
sure your design can withstand scaling beyond the immediate future.
Unfortunately I've seen too many systems designed, built, and
deployed, and only later have it determined that some of the basic
design assumptions were false.  This had the unforutnate consequence
of causing massing scaling problems (the system was being used far
more than ever anticipated, in ways never conceived by the original
designers).

I would certainly LIKE the system to scale to 100 clerks.  But I think
scaling to two would be good enough. :)

This really boils down to the fundamental question of whether clients
should have live data.  I feel that yes, they should.  Clearly you
feel that no, they shouldn't.  I suppose we must agree to disagree
here.  However I should point out that in my system your client just
wouldn't register for callbacks and you get your desired behavior.  In
your system, you cannot achieve what I want ;)

-derek
-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available