Server Side Documentation

This document explains Yote server side programming. Server side programming is done using simple object oriented perl. There are no tables or schemas to deal with. There are a few simple concepts to grasp and conventions to keep.

Yote objects are organized in a heirarcical data structure. Each Yote object finds one or more paths to the YoteRoot at the base of the graph. Yote Objects are basically containers of key value pairs where the values may be other Yote objects, hashes, lists and scalars. All Yote objects are descendents of Yote::Obj. Yote::Obj provides some automatic getters and setters as well as some other convenience methods.

Yote objects are loaded as needed. If one Yote object is attached to an other, it will not be loaded from the database until the get_obj method returns it. This allows there to be a huge cohesive data tree that does not have to be loaded into memory all at once.

Only one master process executes the Yote code and communicates with the data store. Server processes all talk to the master process, which executes from a list of queued commands. The server process adds a command onto a shared queue, which the master process reads from and executes, one at a time. The server thread waits on a shared variable to be released by the main thread and returns the result contained within to the client. Optionally the server thread can place a command in the queue and not wait for the answer.


Creating a new Yote object is as easy as my $obj = new Yote::Obj();. Once created it can be attached anywhere in the tree and will persist. If it goes out of reference when it is not in the tree, it is lost forever.

Getters and Setters

Yote uses get_ and set_ explicitly for getters and setters. This makes it clear what is happenening, and allows yote to understand what is being asked of it. The foo in the cases below is a field of the Yote object.

These are exposed to the client side in most cases. A client object will have get_foo and set_Foo methods attached with these rules :

Public Methods

Yote Objects provide a stock of other methods. If a subclass of Yote::Obj is created, any methods that do not begin with an underscore are considered to be public, and automatically exposed to the client javascript.

Private Methods

Method Signature

All public methods have the same signature. This is required so that the client and server can connect to each other. The method signature is

$yote_obj->mymethod( $data_scalar_or_reference, $user_account, $environment );

These parameters are passed in automatically by the app server as the client invokes them. All arguments are optional.

Yote has defined a number of classes for apps and provides specific behavior and handling of them. The App objects that a developer will use directly.


Credentials for a user associates the user with a Login. The Login is global across the whole Yote system and have several accounts associated with it. Just as a member of a bank may have several account for one person, a Yote user will have an account for each app.
The Login the following automatic methods defined for it:


Accounts are automatically and transparently created the first time a logged in user uses an app. Accounts are just bundles of data specific to the app and user. Accounts are also messengers, with convenience methods for sending and receiving messages from other users of the app.


Objects that are AppRoot objects are singletons which hold onto user account data in addition to other data. They are requested on the client side by calling $.yote.fetch_app( 'package name' ). If the package is visible to the Yote server by being in the perl path or the lib directory under the server root, the singleton will be created and returned to the client.

All objects relevant to the App can trace a path back to this root object. Any App Root resides inside the YoteRoot.

Public Methods

Private Methods


Yote provides a mechanism to upload files. These files, once uploaded, are stored on a the filesystem and have a FileHelper object that provides access. This has a single public method : Url which returns a url to the actual file to the client.

Yote can be useful for programs that do not connect to a client. The ability to create complex and fluid datastructures on the fly is a powerful prototyping capability.