<commit_before>Cher Design -*- outline -*-

* Why Cher?
The basic function of this layer is to allow the sharing (Cher-ing) of
information among different nodes in the network. Plus, I don't think Cher
has ever had a software system named after her and it's high time. Imagine
Cher as the social lubricant that allows the party goers to communicate.

* Overview
The Cher layer implements the distributed object services described in the
Cocktail design document. It does this within the context of an extensible
client/server application framework. Cher provides services that can be
integrated into your distributed application to share information between
a set of clients and entities operating on the server.

* Invocation services
To facilitate the client invoking code on the server (in a
request/response arrangement) and the server invoking code on the client
(in an asynchronous notification arrangement), the invocation services are
provided.

We make use of reflection to make the invocation services feel a bit like
remote procedure calls. All invocation traffic is managed by the
invocation manager, part of which resides on the client and part on the
server.

There are three classes involved when fully using the services. They are
the service class, the provider class and the receiver class.

** Service class
The service class provides the client-side API to the request/response
component. For example:

public class ChatService
{
    public void requestTell (String username, String message, 
                             Object rsptarget);
}

The tell() implementation would wrap the arguments up and pass them off to
the invocation manager for delivery to the server. If provided, the<commit_msg>Added a note on authentication and bootstrapping.<commit_after>Cher Design -*- outline -*-

* Why Cher?
The basic function of this layer is to allow the sharing (Cher-ing) of
information among different nodes in the network. Plus, I don't think Cher
has ever had a software system named after her and it's high time. Imagine
Cher as the social lubricant that allows the party goers to communicate.

* Overview
The Cher layer implements the distributed object services described in the
Cocktail design document. It does this within the context of an extensible
client/server application framework. Cher provides services that can be
integrated into your distributed application to share information between
a set of clients and entities operating on the server.

* Authentication and bootstrapping
The client initially transmits an authentication request to the server and
receives an authentication response in return. If successfully
authenticated, the client will then start up the distributed object
machinery, but will remain in a less functional state until the server
delivers the bootstrap notification.

The bootstrap notification contains the client's distributed object oid as
well as the invocation services oid. With this information the client can
complete initialization and attain a fully operational state.

The motivation for splitting up the authentication response and the
bootstrap notification is because the authentication process completes
separately from the server's client management initialization. The
authentication machinery replies to the client and sets the client
management machinery in motion. When that completes (and a client object
has been created for the client), the bootstrap notification is sent off
and normal operation ensues.

* Invocation services
To facilitate the client invoking code on the server (in a
request/response arrangement) and the server invoking code on the client
(in an asynchronous notification arrangement), the invocation services are
provided.

We make use of reflection to make the invocation services feel a bit like
remote procedure calls. All invocation traffic is managed by the
invocation manager, part of which resides on the client and part on the
server.

There are three classes involved when fully using the services. They are
the service class, the provider class and the receiver class.

** Service class
The service class provides the client-side API to the request/response
component. For example:

public class ChatService
{
    public void requestTell (String username, String message, 
                             Object rsptarget);
}

The tell() implementation would wrap the arguments up and pass them off to
the invocation manager for delivery to the server. If provided, the
{'fraction_non_alphanumeric': 0.028552308721838057, 'fraction_numerical': 0.0, 'mean_word_length': 4.5632754342431765, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '778976', 'n_tokens_mistral': 975, 'n_tokens_neox': 930, 'n_words': 650}