<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
</head>
<body>
Bob:<br>
<br>
According to our talk this morning, here's how I'll handle your concerns.
We didn't discuss the publicId question; I need info from you on that one.<br>
<br>
As for the motivation being removed: I'll fit that back in.<br>
<br>
Tom<br>
<br>
<br>
<br>
Robert Olson wrote:<br>
<blockquote type="cite"
cite="mid5.2.0.9.2.20030331101923.01d597f0@pop.mcs.anl.gov"> At 09:43 PM
3/28/2003 -0600, Thomas Uram wrote:<br>
<br>
<blockquote type="cite" class="cite" cite="">I've taken Bob's application
services document, made some changes to the interface, and recast it in
the format used in our other design documents. This part will be included
in the main venues design document, but I wanted to send it separately to
simplify review. <br>
<br>
Bob: Mostly, I made the following changes:
<ul>
<li>the data channel is not a web service; therefore, applications do not
register with the data channel for particular event types </li>
</ul>
</blockquote>
<br>
Whether they register for event types is orthogonal to whether the data channel
is a web service. An app registers for event types because it is interested
in receiving those (and only those) events</blockquote>
At this point, the event service will send all events to event clients, and
applications will register callbacks with the event client based on event
type. Sometime in the future, we can enable event clients to register with
the event service for particular event types, but that's not the immediate
plan.<br>
<blockquote type="cite"
cite="mid5.2.0.9.2.20030331101923.01d597f0@pop.mcs.anl.gov">
<blockquote type="cite" class="cite" cite="">
<ul>
<li>an application object is created with a single data channel, instead
of relying on the application to create the data channel(s) it needs; at this
point, I only see the need for one data channel; the </li>
</ul>
</blockquote>
This is meant to be a general solution. What if I don't want a data channel?
What if I want two data channels in order to make my application logic clearer?
</blockquote>
The current design is to create a single event channel for every application.
An application can choose not to connect to it. An application that needs
two data channels will probably not come around before AG2.1, when we can
consider adding such functionality.<br>
<br>
We talked about distributing application clients with an application stub
that encapsulates knowledge about the application's needs, including the
number of data channels it uses. I like this idea, and we should consider
it for a time beyond AG2.0.<br>
<br>
<blockquote type="cite"
cite="mid5.2.0.9.2.20030331101923.01d597f0@pop.mcs.anl.gov">
<blockquote type="cite" class="cite" cite="">
<ul>
<li>AppObject.CreateDataChannel method has been removed </li>
<li>the application object does not assign a public_token to components;
instead, the public_id in the ClientProfile will be used </li>
</ul>
</blockquote>
The venue client's public id? what if I create an app that stands alone
and isn't part of a client? What if I create two instances of an app associated
with one client?</blockquote>
We didn't discuss this point this morning. The stand-alone app could instantiate
its own venue client, as the shared browser has been doing. The behavior
in the second case probably depends on the app. I think we need to look
at examples of each of these cases to decide how to handle them.<br>
<blockquote type="cite"
cite="mid5.2.0.9.2.20030331101923.01d597f0@pop.mcs.anl.gov">
<blockquote type="cite" class="cite" cite="">
<ul>
<li>we only have one application type, so there is no application service/factory
to create them </li>
</ul>
</blockquote>
I don't follow; how does an application get created if there's not a factory
to create them?<br>
<br>
What if I wnat to derive a custom application class that has server-side
code in it, and create an application server, all using this same framework?
The app factory is a general mechanism..</blockquote>
<br>
Right now, the venue is instantiating app objects itself. I'll move that
out into an app factory, so developers can construct server-side applications
without modifying the Venue code.<br>
<br>
Tom<br>
<br>
<br>
</body>
</html>