[Fresco-devel] IRC MEETING Jan. 19th, 23:00GMT - Summary

This is a MIME-formatted message.  If you see this text it means that your
E-mail software does not support MIME-formatted messages.

--=_heaven-25358-1074622597-0001-2
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi!

We had a very productive IRC meeting yesterday, the logs are up on
  http://www2.fresco.org/irc.html

The purpose of this meeting was to get a consensus on the requirements
we have for future versions of Fresco and which changes are necessary
to achieve those. So far we only settled on the requirements, so we
will have another meeting next week. Please register your schedule on

   http://wiki.fresco.org/IRC

I will announce the date and time tomorrow.

I hope there will be as many motivated people online then as we had this
time: Thanks guys, that was a boost to my morale (and those of the others
too I am sure)!

First we did some brainstorming on what each person thought to be a
key feature of Fresco and then we went on discussion each of the topics
raised (plus some mentioned on the introduction page of the web that were
forgotten;-). We managed to find a consensus on each of them:

  * vector graphics and device independence:

     Nicholas said that we cannot be fully device independent since some
     applications will need to work on pixels and widgets and fonts need
     to be aligned on the pixel-grid, influencing the layout.

     We agreed that this should be transparent to the clients as far as
     possible, but that clients need to be able to request this kind of
     information.

     The actual consensus was:

       clients can ignore the pixel grid if they don't need any specific
       control

  * Scalability:
     =20
     It was undisputed, that Fresco will target "normal" PCs first and
     then extend to 3D workstation class of hardware.

     We further want to get down to high end PDA style systems with a
     reasonably sized display and a FPU (non-FPU CPUs make no sense with
     Fresco's vector graphics).

     The actual consensus was:

       Fresco will target PCs, high end (3D) hardware and PDAs with FPU and
       a good screen last.

  * Location Transparency

     We want that;-)

     The server will run in one address space, each one responsible for one
     scene-graph (which in turn is displayed on one or more heads).

     The actual consensus was:

       Fresco will support multi-head (one server managing several graphic
       cards).

       Fresco will not support a "multi-server" setup (which I defined to be
       like multi-head but with one server per head)

       One scene-graph per server

     Each client will be able to embed others. How that is going to happen
     depends on technical aspects of the system we will need to discuss next
     time. So so far the consensus is a bit vague:

       Embedding is a nice thing to have, but the details will depend on
       other aspects of the architecture=20

  * Flexibility, Extensibility

     We will no longer support client side graphics (objects that full fill=
 the
     Graphics interface, living in the client's address-space) as they are a
     hazard to robustness.

     We do need to allow users to install their own set of (additional) kits
     containing custom graphics.

     The actual consensus was:

       No client-side graphics but the user should be able to install kits =
for
       himself.
    =20
  * Modularity

     Everybody agreed that the Kit-concept we have is fine. We will need to
     add some form of versioning though (see Consistency/Usability discussi=
on)
    =20

     The actual consensus was:

       Kits are a good mechanism for modularity. We did that right.

       Investigate interface versioning.

     The consoles will need to evolve to adapt to new targets, the DrawingK=
its
     won't need to be client-visible anymore if the scene-graph becomes acc=
essible
     only be the server. This allows more freedom wrt. the rendering back-e=
nd.

  * Language Transparency

     We want that. C++ and Python are a must, other languages should be ava=
ilable,
     too.

     The actual consensus was:

       Python and C++ are a must.

       Other languages (everyone) can come later.

       Some form of IDL is a must.

       language-independent wire protocol with language specific runtime
       environments

  * Consistency/Usability

     Not much news here...

     The actual consensus was:

       We encourage consistency with our Kits approach

       We should focus on usability as we go

  * Semantic Abstraction

     This is mostly an issue of writing Kits that support it, so the impact
     on the overall design should be low.

     The actual consensus was:

       Fresco will offer access to its functionality at different abstracti=
on
       levels.

       Fresco will allow for the creation of a document centered architectu=
re

The next step is to discuss how these requirements will influence the future
design of the fresco project. All design decisions we made so far are open
for discussion, join in if you like.

--=20
Gruss,
Tobias

------------------------------------------------------------
Tobias Hunger           The box said: 'Windows 95 or better'
[email protected]                      So I installed Linux.
------------------------------------------------------------

--=_heaven-25358-1074622597-0001-2
Content-Type: application/pgp-signature; name="signature.asc"
Content-Transfer-Encoding: 7bit
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFADW8Qv0FZW3NyoqURAkVXAJ97pd/8v7cdi2LQfIF1MMd6txG/WgCfUkTF
B7mHwVaVTJJc/TREBKLKSJ4=
=Y6um
-----END PGP SIGNATURE-----

--=_heaven-25358-1074622597-0001-2--