|
From: Artem B. <ar...@v2...> - 2003-04-15 14:09:04
|
resending due to ml problems
---------- Forwarded message ----------
Date: Tue, 08 Apr 2003 17:27:27 +0200
From: Artem Baguinski <ar...@v2...>
To: sim...@li...
Subject: (**) simca and corba
hi simca-dev
here's my thoughts about corba, name-servers etc.
first of all, i'm introducing tech level sterretjes. they are like stars
in tv guide, but represent tech-details level of the mail (or it's
part). (*) - isn't technical at all, (**) is technical but can be read
and understood by everybody in this list, (***) - more details, read if
you wanna know more about v2_jam software, (****) - only read if you're
artm or simon, (*****) - low level tech documents with program listings
and comments in russian :)
the symbols should appear in the subject line, although (*) and (**) can
be omitted (because everybody should read those mails generally). if
subject line contains tech-details-code, but then in letter body there's
other code, it means there's end of too-tech section below, and you can
skip there if you're not interested in details. this trick should be
used by programmers to attract attention of others to some conclusions,
like in this mail. end of section is (/*), (/**) etc. there shouldn't be
more then one detailed section per file though, otherwise the whole
thing becomes too serious :)
(****)
if you're not simon skip through to the (/****)
the evil of the current approach (name-server is a thread of one of the
servers) is that if that server dies (e.g. client did something very
wrong and server couldn't recover) then name server dies as well. all
other servers will be inaccessible then.
why not implement the following strategy:
- simca-name-server isn't simca-server, it only implements the corba
naming service and the IOR server.
- simca-server implements the actual simca stuff and registers itself in
a name server. which name server can be specified on command line:
* default: localhost:<simca-port> (we should decide which port)
* --ns-ior <ior> - use name server by ior, exit if no such server
* --ns-ior-file <file>|- - read name server IOR from file or stdin
* --ns-host <host>[:<port>] - use name server by host and probably
port (default for port is simca-port of course).
this approach allows, for example, easily create a setup with
centralized name-server (all simca servers start with --ns-host
simca-hq:9999).
now, about server names. several servers can run on the same host (so
that when one falls others remain running). this means that every server
should be registered with distinguishable name. server name should be
command line parameter, and there shouldn't be default - one must be
provided.
corba naming service allows tree (or even graph, they say) of names to
be created, similar to dns or filesystem. components of this tree
contain not only names but also "kinds". kind describes what for
name-component we have here, if i'm not mistaken we can come up with our
own kinds.
the convention (from name-client):
- components of name are delimited by '/'
- id and kind of those components are delimited by '.'
examples of a name:
/presentation.folder/servers.folder/audio.server
/presentation.folder/servers.folder/video.server
/presentation.folder/servers.folder/audio.server/in.page
/presentation.folder/servers.folder/audio.server/out.page
i don't know actually if the same name can designate object and
context like i've shown.
although, centralized approach isn't good for iternet based sporadic
jams or travelling jam artists who want to start up jam quickly not
changing much in their usual setup. i'll think about this more.
(/****)
this allows the following scenario of using v2_jam for creating portable
distributed installations:
* the description of the installation consists of two parts:
* jam pipeline. pipeline consists of virtual named servers, which
in turn contain pages, and those are made up of connected objects.
* jam map. jam map contains information about where the virtual
servers run. (i.e. maps server names to network addresses)
* whenever author wants to recreate his work in different network
environement he only needs to change the map, and not touch the pipeline.
pipeline/map can be represented either by passive documents (e.g. XML
based) or by active scripts, or by combination of the two.
|