DSMCC P
ROTOCOLS
AND
I
NTERFACES
As revised 2006.05.04
Bionic Buffalo Tech Note #55
Security:
Unrestricted
11. Objects to Be Implemented on Either the Client, or the Server, or Both
Objects with certain interfaces might be implemented on the client or on the server, depending on the
context and application. When implemented on the client, there is no expectation of invocation by any
server application. This section describes those client or server objects.
DSM::Directory
is an extension of the standard
CosNaming::NamingContext
service used in
most CORBA environments. As
CosNaming
is described in depth elsewhere, it will not be discussed
much here. This discussion will be limited mostly to the extensions.
DSM::Directory
will be implemented on the client for local client objects (as, for instance, if the
client has a local filesystem), and for objects downloaded from an object carousel. It will be
implemented on the server for objects residing on the server.
DSM::Directory
defines a
PathSpec
structure, which is different from a
CosNaming::Name
.
While a
Name
represents one object (as with “colour/red”), a
PathSpec
may represent multiple
objects. Although there is no defined string representation for a
PathSpec
, we might imagine a
representation such as “colour/red,green,blue” to represent three objects named red, green, and blue.
CosNaming
defines various operations on a
NamingContext
object. A
NamingContext
corresponds roughly to a directory of objects, with each object bound to a name.
NamingContext
s, as
objects themselves, may be bound to names in other
NamingContext
s, resulting in directory trees. In
addition to the operations inherited from
CosNaming::NamingContext
,
DSM::Directory
has
four additional operations:
open()
resolves the (possibly multiple) objects associated with a
PathSpec
close()
deletes the resources associated with a reference to the
Directory
get()
returns attribute values associated with the objects associated with a
PathSpec
set()
sets attribute values associated with the objects associated with a
PathSpec
DSM::File
represents an ordinary file, with
read()
and
write()
operations. It will be
implemented on the client for local client files and for files downloaded from an object carousel. It will
be implemented on the server for files residing on the server.
DSM::Stream
represents streaming audio or video content. It includes methods to control playback:
pause()
,
resume()
,
status()
,
reset()
,
jump()
, and
play()
.
A
Stream
object in a server is implemented on the server. The client must, of course, implement code
to handle the incoming data, but the
DSM::Stream
operations are implemented on the server object. A
single instance of a
Stream
object may handle multiple simultaneous client connections. (This is
unlike some nonDSMCC architectures which replicate a content object for each user.)
Copyright 2006 Bionic Buffalo. All rights reserved.
File tn0055; Modified 20060505 12:45:42
http://www.tatanka.com/doc/technote/index.html
Email: query@tatanka.com
Page 16 of 20