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

[David Merrill]

On Tue, Jan 02, 2001 at 04:53:50PM -0500, Derek Atkins wrote:
> 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 ;)

You have just given me 3 good reasons for live updates: there *are*
likely to be simultaneous users even in small installations, you
*have* to refresh before you can do a commit, and therefore network
traffic *is* an issue. Fine. Sold me. Next issue. :-)

-- 
Dr. David C. Merrill                     http://www.lupercalia.net
Linux Documentation Project                dmerrill@lupercalia.net
Collection Editor & Coordinator            http://www.linuxdoc.org
                                       Finger me for my public key

Three from the hall beneath the tree
	Is, Was, and Shall Be
Come Wyrd Sisters swoop to the ground
Loosen the web that binds us down
Join with the hands of the Weavers Three
	Is, Was, and Shall Be
		-- Is, Was, and Shall Be, Beverly Frederick