Re: Deployment of CCI
Joel Crisp ([email protected])
Tue, 6 Dec 1994 08:55:41 +0000
> From [email protected] Tue Dec 6 01:39 GMT 1994
> Date: Tue, 6 Dec 1994 02:33:02 +0100
> Originator: [email protected]
> From: Paul Burchard <[email protected]>
> To: Multiple recipients of list <[email protected]>
> Subject: Re: Deployment of CCI
> X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
> X-Comment: To sign off, send mail to [email protected] with body DEL
> WWW-TALK
>
> Yosi Mass <[email protected]> writes:
> > I have been playing with CCI (Common Client Interface)
>
> > and Mosaic 2.5b and found it very powerfull.
>
> The current version of CCI has a fatal flaw: it does not communicate
> the URL of data passed between different viewers.
>
> Because there are an increasing number of Web-enhanced formats
> (Hyper-TeX, WebOOGL, VRML, etc.), assuming the HTML viewer to be the
> "master" is no longer a viable model. In order for relative URLs to
> work, viewers must communicate *full* information about the data to
> be displayed by another viewer, including (especially) its URL.
>
> --------------------------------------------------------------------
> Paul Burchard <[email protected]>
> ``I'm still learning how to count backwards from infinity...''
> --------------------------------------------------------------------
>
This ties up with a discussion I had with Simon Spero at the Chicago
conference. There is emerging a picture of requirements which people
have raised which is heading in the direction of a browser implementation
along the lines of X-Windows Window Managers. This would have a user
interface controller, preferences database, and the ability to zone a page
handing over control of each zone to a module capable of viewing the
appropriate data. This would allow more tightly integrated 'pages' of
text, graphics, vr etc. It would be more extensible, particularly if the
back end is also a modularised protocol suite.
There are obviously also disadvantages to this model, but I think that
the current trend for UNIX browsers to use this type of idea anyway (
with the X-windows window manager being the integrator ) shows that people
like it. Making this approach more tightly coupled would present a
'neater' view to the user.
I believe that the tk-WWW browser is already heading down this route ?
Advantages
1) Extensibility
2) Tighter coupling between connected data in a 'virtual page'
Disadvantages
1) Needs metainformation for requested size of 'zone', gravity, scroll
attributes etc.
2) Requires a SET of standards for controller -> viewer communication and
viewer->controller->protocol module communication
3) Probably requires standards for viewer ->controller->Viewer manipulation
( go via the controller so that e.g. mappers can work properly )
Any comments ?
Joel