Total Knowledge Projects Jobs Clientele Contact

UU Tech

Personal tools
From Total Knowledge
(Difference between revisions)
Jump to: navigation, search
Line 15: Line 15:
== [[Scalability]] ==
== [[Scalability]] ==
== [[Text Handling]] ==
{{:Text Handling}}

Revision as of 08:38, 29 May 2009

Technological aspects of UU implementation.


Tech notes


Like in Wiki, there are two kinds of edits:

1. Versioned edits
2. Minor edits

Minor edits do not create new versions of the document, but change existing version instead. As such, they are irreversible. Only latest version can be edited.

It is author's decision, wether to designate change as minor or as versioned.

When a new version is created, all objects linking to this one are notified. Their action can be one of the following:

  • Silently use new version
  • Use new version and notify owner
  • Notify owner and keep old version
  • Silently stick with old version

Object References

Shareable object references can be aware of versioning in following ways:

1. Always use latest version of referenced object
2. Always stay at current version
3. Notify author of referenced object updates

In all of these cases, changes to referenced object do _not_ constitute changes to referenceing object.

Object change notifications

There are few ways to notify referrer about change of referenced object. When reference is made, referer choses what he wants.

Email notification

* Each change - an email
* Digest - user gets summary of changes in all objects once in a while

Special page

Special page which provides filtered summary of changes, i.e. for all objects referenced by given course.

Object Edit Flow

Logically object editing follows this pattern:

1. Edit Object action is requested. It creates a temporary copy of an object
2. User edits and saves the copy (it can be saved as many times as needed)
3. When user is satisfied he executes "Release" action. Minor/Versioned edit
   is a required parameter for edit action. Probably will be implemented as
   radio button, that does not have initial value set (to avoid user forgetting
   to decided what kind of edit is it)

Internally object editing translates to following:

1. Edit Object action is requested. It creates a new version of an object in unpublished state (not visible for anyone besides author(s)). 
2. Any child objects connections are copied from the prior version.
3. User edits and saves the copy (it can be saved as many times as needed)
4. When user is satisfied he executes "Publish" action. Object is switched to published state.
5. All the connections to the parent objects are processed. The action on every connection is performed as defined in version_policy field of the connection.

Minor/Versioned edit is a required parameter for edit action. Probably will be implemented as radio button, that does not have initial value set (to avoid user forgetting to decided what kind of edit is it)


UU will have clustering capability. It is not 100% clear what kind of clustering support we will have, and how it will be implemented at this point.

Both database and application server need to be scalable in order to maintain flexebility.

There is some rudimentary clustering support in PostgreSQL to the best of my knowledge, but I don't know anything about details, so that needs to be researched.

There is nothing currently built into CPPServ in terms of scalability, but few things are pretty easy to implement. For example, we could add load balancing support to the front-end module, which would allow us to distribute requests between CPPServ instances. It could track which request belongs to which session, and forward it accordingly.

Alternatively we could implement session state sharing, and then use some external load blancer like vserver.

Text Handling

Text in UU will be represented with a safe subset of XHTML for the most part. We might add few extensions, for inserting media, Math formulas (MathML? LaTeX?)

Text Editor

Editing will be done with TinyMCE. We'll have to write a plugin for TinyMCE, to provide simple UI-based access to multimedia objects.

We shall also provide simple plain-text editing ability for non-JS, or pure-text browsers.

On the backend, we will need a filter system, which would verify validity of the text according to the following criteria:

  • Only allowed XHTML tags are used
  • All media references are valid
  • All formulae are compileable

Sets of allowed tags and MM objects will depend on kind of text

Multimedia Objects

Once the validation is passed, list of media references will be extracted, and UMO parent-child relationships with corresponding media objects will be established.

Links to multimedia objects work just like any other umo links (new versions will notify owner or just auto-update. The only question here is if we want to auto-rewrite original object with new IDs when switching to new media object version, or if we want to make separate IDs for such links, which will be permanently preserved.


Final HTML should be cached. It would make sense to cache it at the time object is published, since published version is immutable.


On the back end, any rich text will be represented as XML, which will include subset of allowed HTML tags (perhaps configurable by administrator) and our special tags for embedding media. Whenever such text will be needed for display purposes, the theme will request it, passing in an object which implements ITextRenderer interface, providing functions for turning embedded objects into HTML tags (in fact they'll have to return corresponding sptk::CXmlElements).

Overall procedure will be as follows:

  • get root element of the text to render (does not have to be complete document)
  • call uu::util::parseText(), pass in the root and the renderer
  • parseText will go through all tags, applying the renderer as needed and will throw an exception if invalid tag is encountered.
  • parseText will serialize resulting XML tree into a string and return it.

Embedded media objects (images, flash, etc.) are stored as separate UMOs, and thus must be linked to the UMO being rendered, in order to be used. These objects are referenced in the text through base ID of the embedded UMO. When UMO is published, umo_to_parent_umo ID is supplemented in the text. This way all the normal rules for versioning and relations between UMO versions apply, and at the same time the need to keep track of media UMOs is reduced and the procedure is simplified.