[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [proposal] url package



What you have below may suffice for a simple "bare-bones"
protocol. 

In general, one way want to support co-browsing. For instance,
one may want events generated as a player browses on one client
to be communicated to the server, which may broadcast them to
other clients in the associated context (other players connected
to the room), causing their browsers to display the URL
(activating them if necessary). 

One way to understand some of the power and generality of this
approach is to look athe HotJavaBeans available from javasoft (go
to www.javasoft.com, Products), and think of generating
appropriate MCP 2.1 versions of the interfaces supported by the
various beans.

   X-Sender: rgodard@mime.unige.ch
   Date: Sat, 14 Mar 1998 12:29:59 -0500
   From: Richard Godard <richard.godard@tecfa.unige.ch>
   Sender: owner-mcp-dev@research.att.com

   I was thinking about a url package that would be derived from the MCP 1.0
   display-url package.

   The goal of this package is to offer the server a way to notify the client
   to display and/or download URLs. This is very handy for all kind of
   applications (e.g. synchronizing a web interface with the client,
   downloading files, diplaying multimedia content, etc...)
   This package does it in a straighforward and loose way. I.e. its is not
   strict about what the client should do with the display/download messages.
   Insteed it's giving indication to the client of what is expected.

   Server to client message:
   -------------------------
   * display (url [, target])
   Request the client to display the url (in the target frame if that info is
   provided and if the client can handle it.) If the client can't display the
   url but can dowload it, it should do so and let the user know what's
   happened.

   * download (url)
   Request the client to download the file pointed by the url and notify the
   user about it (the best would be to offer the user a dialog box so that
   s/he can choose where the downloaded file is placed, but that's not
   mandatory.) If the client can't download the url but can display it, it
   should do so and let the user know what's happened.

   Suggestions/comments?

   Janus