Re: how to get rid of XFree in the longterm (just a thought)

From: tom (tom_at_dbsevice.com)
Date: 02/27/04

  • Next message: Peter Keller: "Re: KDE won't boot... DCOP errors" 
    Date: Fri, 27 Feb 2004 00:14:49 +0100

    Wayne Throop wrote:
    >
    > Over time, I think it will become the rule rather than the exception.
    > As devices get smarter, and they all want to display information mutiple
    > places at once, it'll get more crucial. Consider a media server and
    > multiple distributed consoles. Sure, you could make the server handle
    > only the streaming protocols and run all apps locally on smarter
    > terminals. It doesn't *have* to be the display protocol that goes over
    > the net. But you'll still want to be able to talk to some app at one
    > location, and then pick up where you left off even after you want across
    > the house to another console; or start doing something on a pocket
    > console, and decide that you'd like to move what you are doing to a wall
    > screen; or run an app which only runs on one box (requires special
    > hardware, or extra memory resources, etc etc) but you don't happen to be
    > at that box's main screen; or you have two people wanting to use such
    > resources at once; or any of tens of other useful applications of
    > consuming memory and cpu resouces here, and displaying there.
    >
    > I think such uses would already be fairly commonplace in many homes
    > with multiple computers (which are becoming more and more common)
    > if it weren't for the fact that people have gotten used to it
    > being impossible.
    >
    > IIRC, even microsoft fielded a product to allow a second special-purpose
    > display console to borrow resources from another machine; their solution
    > was clunky and un-necessarily expensive, but the thing is, people are
    > starting to need to do such things. I'm not that far ahead of
    > the trend. Some, but not that far.
    >
    > : http://www.dbservice.com/tom/system.html
    >
    > Some promising concepts perhaps, but I think the issue of
    > separation of concerns isn't made clear, and is a potential infelicity.
    > For example, application launching and session control are part
    > of the job of network transparent distribution of gui apps.
    > But fusing them together into a single "system", a single API,
    > or parts of a single API, is IMO a mistake. There are more reasons
    > one might want to start remote apps than just GUI apps. So, a model
    > where distribution is handled one way (eg ssh), sessions another
    > way (eg, xdm), and actual graphics ops yet another (X protocol)
    > seem to me to be a feature, not a bug. The point being, using
    > one doesn't force you to use, and pay the overheads for, the others.
    >
    > Not that the way it's done now is unflawed or un-improveable. For
    > one example, dealing with frame buffers (ie, pixels, ala VNC), and
    > sound and keyboards and mice isn't really done well or modularly
    > enough IMO. But one thing that isn't desirable is a monolithic API
    > that tries to do everything there is to be done. A suite of
    > possibly-cooperating but fundamentally independent protocols
    > is, IMO, superior.
    >

    I haven't written it on the page, but I thought that these four
    components are independent, stand-alone applications.
    And the protocols don't have to be the same. For example the app server
    could have a simple protocol which could be extended by modules, e.g to
    add some sort of security to it (ssh or others). I didn't try to make a
    monolythic API, I didn't even define an API, this page only reflects how
    I think a system of GUI applications and display servers should look
    like. I agree with you that making things more modular, or even split
    things totally off could help. Making the four parts of the system
    independent could help to bring some competition to the market. 

    -- 
wereHamster a.k.a. Tom Carnecky   Emmen, Switzerland
(GC 3.1) GIT d+ s+: a--- C++ UL++ P L++ E- W++ N++ !o !K  w ?O ?M
           ?V PS PE ?Y PGP t ?5 X R- tv b+ ?DI D+ G++ e-- h! !r !y+
  • Next message: Peter Keller: "Re: KDE won't boot... DCOP errors"

    Relevant Pages

    • Re: how to get rid of XFree in the longterm (just a thought)
      ... > only the streaming protocols and run all apps locally on smarter ... > console, and decide that you'd like to move what you are doing to a wall ... > of the job of network transparent distribution of gui apps. ... But one thing that isn't desirable is a monolithic API ...
      (comp.os.linux.development.apps)
    • Re: How to pass information, classes between forms in Windows Application mode
      ... example fails to be instructive for several reasons: it's console ... Forms apps aren't ... There's still no such thing as a forward declaration. ... in WinForms apps as console apps ...
      (microsoft.public.dotnet.languages.csharp)
    • Re: Moving From ProTools to Linux? Good or bad?
      ... production apps. ... part of the tail end of the BeOS history was that TASCAM ... small/medium format digital recording console (or recording console ... my experience with open-source apps is that one has to be ...
      (rec.audio.pro)
    • Re: .NET and Delphis future
      ... Big name products are still being built for API. ... Real objects, decent languages, business apps ... The world's best kept secret is that an experienced programmer when writing ... desktop apps gets the most value for $ with Delphi. ...
      (borland.public.delphi.non-technical)
    • A common GUI API for Linux, is it possible?
      ... A common GUI API for Linux, ... I use all kinds of apps on Linux; apps from QT and apps from GTK and some ... a program expects to call a function in the GTK ... When Firefox is running and calls a GTK library, the new toolkit ...
      (comp.os.linux.development.apps)