Re: [Fresco-devel] cache graphics

Hi all :-)

Nick Lewycky wrote:

> your CacheGraphic::traverse() ... claiming that it will never block. 
> It then procedes to call into the Graphic--a method which may never 
> return.

Why can't it open a new thread and make the call in that thread? 
Stefan's reply was too concise for me.

> * Fresco must be entirely ignorant of the underlying pixel grid yet 
> render perfectly on a given display.

Was that a requirement or a server-internal design choice? For the APIs 
towards the app, it's irrelevant, if the Graphic, drawing traversal or 
Drawing Kit knows about pixels, assuming that the app doesn't implement 
|Graphic|s.

> There are a few options. For example, Java is a technology that allows 
> someone to run untrusted code. (Bad because we want to be language 
> agnostic.)

And bad, because it didn't work. It was a nice idea, but I haven't seen 
a "sandbox" which reliably kept in the evil boys in. Running untrusted 
code is a bad idea(TM).

And even if you just expose APIs: the more ways you give the evil guys 
to play with you, the more chances they have to find a hole. Compare 
webserver-CGIs, network servers and desktops opening network sockets.

> What is Fresco supposed to achieve? What do we require from it?

Hard to answer so generally. Everything that *can* be achieved and makes 
sense. ;-)

> the whole "fresco separates device from look rather that separating 
> presentation from content" problem still rings in my ears.

Did I miss something here? (IRC discussion?) I considered the separation 
of the application from the concrete presentation one of the main 
strengths of Fresco and I very much like(d?) that. I want the app to 
specify that "there are 2 panels, 50/50, and the right panel has 3 radio 
buttons, aligned vertically", and all the rest is up to Fresco's kits. 
(In fact, I want the app to not even specify such layout, but that's 
another layer offtopic for now.)


To answer your question from my perspective:

I can only tell what *I* liked about Fresco's goals, from what I understood:

    * Clean and simple API, which is long-term stable and easily
      adaptable to new requirements, even unforseen ones. Also very
      comfortable / efficient for the programmer.
    * Separation of apps from concrete look and behaviour, and by
      extension from concrete devices used.
          o Frees the programmer from making pixel adjustments
          o Allows the app to run well with other languages and devices
          o Allows the user to customize the look and feel of all apps
            at once
    * Fulfilled by CORBA:
          o Language agnosticism in app API
          o Remote apps
          o Potential to use a large number of existing solutions, like
            for resource discovery.
          o Assuming the programmer knows CORBA, also frees him from
            learning yet another component technology and API.
    * Speed, even over the network
      Almost all the direct and time-critical user interaction happens
      in the server process. This is the best solution to remote
      applications that I've seen so far, better than e.g. intranet
      applications. Potential to work even across the ocian.

What I liked about the project's methodology:

    * Doing things right rather than quick and dirty
    * Learning from bright minds and research and applying that instead
      of following the rest of the industry
    * Modularity: Reusing the best existing solutions to well-understood
      problems instead of writing custom solutions and growing them
      organically over time up to the existing solutions, wasting a lot
      of time on offtopic tasks. See CORBA above.

The problems that I see are:

    * Applications have to be trusted atm. It's unclear, if the server
      *can* be hardened enough to allow untrusted applications to run
      securely - maybe that's not feasible.
      That an application can *accidently* freeze the server is somewhat
      a subset of that and should generally not be possible, even if we
      decide applications to be trusted.
      The difference between claiming to protect from *bugs* in the apps
      and to protect from *evil* app writers is that a hole in the
      protection is absolutely fatal in the latter case, while it's just
      a server bug in the former case.
    * Unclear how applications are supposed to extend the server
      functionality, if it can't be achieved by composing server-side
      Graphics. Unclear, if all applications eventually can be
      implemented using server-side Graphics only. For example
          o Some apps will need to react to certain key presses, but
            there currently isn't a way for that.
          o A video player will want to control the pixels, for
            preciseness. The renderer probably has to run on the server
            anyways, for speed. Do you want to run mplayer in the
            server? Compare
            <http://wiki.fresco.org/ArchitectureQuestions>, question
            1.11, end of 4. paragraph.
          o Games. I need the option to run [3D] games in a window, not
            full screen.
    * Manpower/Time. Bright minds in the project, but most of them don't
      have much time. Unfortunately, I can't help out myself either in
      the short-term future.


Respectfully,

Ben