Venues Design, Venue Apps

[Thomas Uram]

Bob:

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.

As for the motivation being removed:  I'll fit that back in.

Tom



Robert Olson wrote:

> At 09:43 PM 3/28/2003 -0600, Thomas Uram wrote:
>
>> 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. 
>>
>> Bob:  Mostly, I made the following changes:
>>
>>     * the data channel is not a web service; therefore, applications
>>       do not register with the data channel for particular event types
>>
>
> 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

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.

>>     * 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
>>
> 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? 

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.

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.

>>     * AppObject.CreateDataChannel method has been removed
>>     * the application object does not assign a public_token to
>>       components; instead, the public_id in the ClientProfile will be
>>       used
>>
> 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?

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.

>>     * we only have one application type, so there is no application
>>       service/factory to create them
>>
> I don't follow; how does an application get created if there's not a 
> factory to create them?
>
> 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..


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.

Tom


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/ag-dev/attachments/20030331/1af76686/attachment.htm>