Re: Informal poll

On Wed, Apr 16, 2003 at 08:27:27AM -0500, Daniel Jackson wrote:
> On Wednesday 16 April 2003 04:28, Micah Dowty wrote:
> 
> > >
> > > Just the (hopefully unnecessary) plea to keep in mind that a major
> > > strength of pg is it's potential good portability to non-Linux embedded
> > > targets. Some of those targets only offer a C-Compiler and limited POSIX
> > > compatibility. Don't leave this market sector to NanoX!
> >
> > Definitely. I'd love to get PicoGUI working on eCos, OSKit, NetBSD, L4...
> > the main problem currently is that the build system is quite baroque.
> >
> 
> Well, time to get people pissed at me. I think if the build system is the 
> thing holding us back from these platforms, then we should fix the build 
> system. 

This is already planned- according to the .plan on picogui.org, the
build system will get overhauled for 0.47

I was hesitant about redoing the build system for pg1, but there were
two good reasons to go ahead and do it:

- The majority of questions I get about picogui are related to build
   system bugs or weirdnesses.

- The new build system should be usable in pg2 also, if it's written
   well

> I don't think we need a rewrite of PicoGUI to operate on these 
> platforms. In fact, from what I've heard of the new system, I'm worried about 
> cross platform compatibility. How well can oM work on eCos, Windows, HP-UX. 
> If PicoGUI has to be staticly compiled on all of these platforms to work at 
> all, because I know for a fact that HP-UX's dynamic loader is wierd and 
> Apache can't use it for it's modules, then what is the advantage of ripping 
> up all we have done so far to build a pie in the sky new system? I think 

Here you're getting into several very different issues. Om will be a
design for an object model, and a protocol specifying how objects
communicate with each other. That's all. Some of the allowable protocols
might be platform-specific, but that's fine- all the protocols are
optional.

I'm not sure what led you to belive that pg2 will require a particular
flavor of linking. One of the new architecture's strengths will be
modules that can be combined in any way you want. During configuration,
you'll be able to specify that you want, for example, one process
containing an object kernel, a layout server, some widgets, a theme
server, and some input and output servers, with TCP/IP connectivity. The
Om interfaces between those components will be optimized as much as
possible at compile time, and a TCP/IP interface will be added so they
can be manipulated remotely.

Then, your application will use Om to connect to picogui via that TCP/IP
interface. The finished binary will act almost exactly the same as pg1
does, but the code will be easier to work with, and the configuration
will be far more flexible. You could optionally make the widgets
dynamically loadable, or remove the layout server and connect one
remotely instead.

As for "pie in the sky"...
I could understand that comment if we were talking about X, and I just
told you that all development on X was going to be completely halted and
we'd start on a new project right away. But PicoGUI isn't X- people use
it, but it's not entrenched to the extent that maintenance should be
favored over innovation. Look at the description of the picogui project
on picogui.org- the whole point of this project is to come up with a
powerful GUI architecture, and pg2 is substantially more powerful than
pg1.

> having your HTML rendering component on a remote machine and attached to the 
> PicoGUI server on the local mahcine is a cool idea, but in the end I think 
> thats all it is, a cool idea. On a large scale, thats going to cause huge 
> problems in terms of bandwidth, and security. I think there is a major case 
> for sticking with PG1, because PG1 is as it's name describes it, its a GUI. 

This is just like all the uninformed masses posting on OSNews and
Slashdot arguing that X would be better if they removed all the
"useless" networking code:

Just because a program can do something you wouldn't want to do doesn't
mean it shouldn't be able to.

In the pg1 architecture, there is a separate layer to handle the
communication between client and server. All pg2 is doing with that is
generalizing it. Now every component of PicoGUI that you may want more
than one of, or to run over the network, is in a separate module.

If you don't want to use these modules over the network, that's fine.
Just link them into one binary like you've always done. But now if you
want a client/server system, it's as simple as adding some form of IPC
to the Om connection.

Now you have a design that's both cleaner and more useful. There's no
networking code closely tied to a particular purpose. You can keep on
using picogui as a simple client/server GUI like it is now, but if you
have a specialized need you can add multiple layout servers, or run a
widget on a different computer. People assume that features == overhead.
With a good design, you get most of your features for free.

The bandwidth use under normal circumstances will be about the same. As
for security, pg2 will be far superior. pg1 had a very simple security
facility based only on object ownership. pg2 will use capability-based
security, which is both very simple and very powerful.

> It is not a distributed computing system. If you want to make a
> distributed
> computing app, then cool! But leave the GUI to be a GUI.

Ah, but that's why this isn't a monolithic lump of code with a little
"GUI" label stuck on top. Om is in charge of all the
potentially-distributed issues. (Note the "potentially"- if you don't
want that functionality, it optimizes out at compile-time)

All the actual GUI code is separated out into manageable chunks that
will no longer be intertwangled with bits of networking or security
code.

--Micah

-- 
"For every problem, there is a solution that is simple, elegant, and wrong."
           -- H.L. Mencken


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf