Weblog Page

Chat

Created by Emmanuelle Raffenne, last modified by Gustaf Neumann 24 Nov 2023, at 06:41 PM

Package Specification Summary for Package: chat

Bug Tracker Summary for Package: chat

Code Metrics Summary for Package: chat

The chat package is currently using two different chat engines:

1. The Java applet and the Java chat server, or
2. the Ajax based chat class from xotcl-core

If no xotcl-core is installed, one can only use the version with Java applet. If xotcl-core is installed, one has to option to choose between both engines via parameter.

In essence, the Ajax based variant is the chat implementation from xowiki plus chat room management and a list of the currently connected users. Originally, the AJAX-based chat class (::xo::Chat) was developed for xowiki, but later moved to xotcl-core such that the chat package does not need a dependency on xotcl-core and xowiki.

Actually, the chat support in xowiki contains a different variety of AJAX based communication strategies:

1. Polling mode (the web browser queries via AJAX in definable intervals the server, and checks, if there is some new information available), and
2. Streaming mode (the client opens a connection to the server, the server pushes the information back to the client. xowiki chat supports two different sub-modes:
   1. streaming of JSON objects via asynchronous AJAX sockets, or
   2. scripted streaming, where the browser loads HTML with embedded script tags in the background from a hidden iframe

Both (2a) and (2b) require libthread installed and NaviServer. However, the advantage of the streaming approaches is that they are much faster in the look and feel and that they are better scalable on sites with a high load. 2a works only on Firefox (not in current versions of IE or Safari) and has the advantage over 2b that the browser does not show the background activity (no spinning wheel in Firefox). 2b is more robust and works with Safari, IE and Firefox (the information about the browser support is from 2006, and most probably different today). Both streaming modes implement, what is sometimes called COMET.

When the chat package uses the ::xo::Chat, it uses it only in currently only polling mode, which has the least requirements. This has been as well tested with (Firefox, IE and Safari).

XoWiki

Created by Gustaf Neumann, last modified by Gustaf Neumann 24 Nov 2023, at 06:36 PM

XoWiki is a wiki implementation for OpenACS implemented based on xotcl-core. Instead of trying to implement the full set of wiki markup commands in systems like MediaWiki, XoWiki is based on a rich text editor and focuses more on integration with OpenACS (e.g. categories, general comments, adp-includes, ad-substitution of template variables). XoWiki combines aspects of wikis (ease of page-creation) with aspects of a content management system (revisions, reusable content, multiple languages, page templates).

XoWiki provides functionalities of enterprise wiki systems (such as combining structured with unstructured information, providing security policies, etc.). XoWiki is reused in several other packages such as XoWiki Content flow, S5 or  the Learning Content Tool.

Documentation:

• Latest version of the XoWiki Documentation
• XoWiki FAQ
• XoWiki Tutorial (XoWiki as a framework)
• ::xowiki::Form examples (Import by XoWiki 'Import' feature in Admin UI)
• Solution Grove's xinha and xowiki howtos

Package Specification Summary for Package: xowiki

Bug Tracker Summary for Package: xowiki

Code Metrics Summary for Package: xowiki

Available Includelets

Available Formfield Classes

XOTcl Core

Created by Gustaf Neumann, last modified by Gustaf Neumann 24 Nov 2023, at 06:31 PM

What is xotcl-core

xotcl-core is an OpenACS package, which provides base functionality for OpenACS applications using XOTcl. The xotcl-core package is used by several other OpenACS packages such as the XOTcl request monitor, XoWiki, XoWiki Content Flow, S5 or the Learning Content Tool.

Install xotcl-core

First, get xotcl-core from the OpenACS repository:

Move xotcl-core to the directory, where your OpenACS packages are stored. We assume, this directory is /usr/local/openacs-4/packages
 

 Next, go to acs-admin/apm (http://YOURSERVER/acs-admin/apm/), choose "install-packages" and install XOTcl Core. Finally, restart the server.

Now you can browse  http://YOURSERVER/xotcl

Functionality of xotcl-core

xotcl-core defines several classes for

• library dependencies
• package management
• debugging
• security and policy management
• HTTP client and server functionality
• Object Relational Database Interface
• ical formatting
• cluster management
• chat handlers

and several utilities.

Tutorial xotcl-core

 See slides

Code metrics and Package Description

Package Specification Summary for Package: xotcl-core

Bug Tracker Summary for Package: xotcl-core

Code Metrics Summary for Package: xotcl-core

The OpenACS package xotcl-core requires in versions of OpenACS before 5.3 the following patches for the documentation procs and the bootstrap installer:

To apply these patches, go to the directory, where the OpenACS packages are stored. We assume, this directory is /usr/local/openacs-4/packages. 
 

Both patches do not harm in case XOTcl is not installed. Now reload these packages or restart the server.

xooauth

Created by Gustaf Neumann, last modified by Gustaf Neumann 24 Jul 2023, at 02:09 PM

Package Specification Summary for Package: xooauth

Bug Tracker Summary for Package: xooauth

There is no package with the name "xooauth" known to bug-tracker.

Code Metrics Summary for Package: xooauth

This package was developed to provide a comprehensive OAuth implementation for OpenACS based on the XOTcl infrastructure. The package contains OAuth core, OAuth client, OAuth server. Currently, just the core part is ready for production use, the other functions are currently deactivated.

The package can be used to

• access external services as registered application (e.g. according to he LMS LTI standard, see also: see accessing-lti-services,  or Microsoft Authentication flows),
• or to authenticate users (see openacs-with-external-identity-providers).

The xooauth component was originally developed by Knowledge Markets.

xowf (XoWiki Workflow)

Created by Gustaf Neumann, last modified by Gustaf Neumann 02 Oct 2021, at 10:41 AM

XoWiki Content Flow - an XoWiki based workflow system implementing state-based behaviour of wiki pages and forms (short intro).

Package Specification Summary for Package: xowf

Bug Tracker Summary for Package: xowf

There is no package with the name "xowf" known to bug-tracker.

Code Metrics Summary for Package: xowf

xowf depends on xowiki.

Workflow Examples:

• A two-chambers legislative process, loosely based on the Italian one. A law proposal is submitted to the first chamber, then passed to the second one. The text keeps being passed between the two chambers until no amendments (changes) are made. Once this condition is met, the law is approved. Workflow example of a legislative process

Contacts Lite

Created by Gustaf Neumann, last modified by Gustaf Neumann 23 Jan 2021, at 01:07 AM

Package Specification Summary for Package: contacts-lite

Bug Tracker Summary for Package: contacts-lite

Code Metrics Summary for Package: contacts-lite

xowf plugin for Monaco code editor

Created by Gustaf Neumann, last modified by Gustaf Neumann 11 Aug 2020, at 09:40 AM

Code metrics and Package Description

Package Specification Summary for Package: xowf-monaco-plugin

Bug Tracker Summary for Package: xowf-monaco-plugin

There is no package with the name "xowf-monaco-plugin" known to bug-tracker.

Code Metrics Summary for Package: xowf-monaco-plugin

Calendar

Created by Emmanuelle Raffenne, last modified by Gustaf Neumann 01 May 2020, at 11:20 AM

Package Specification Summary for Package: calendar

Bug Tracker Summary for Package: calendar

Code Metrics Summary for Package: calendar

Suggestions for improvement (from /forums/message-view?message_id=432244 ):

• different colors for different calendar sources
• easy and nice printout of week and monthly calendar
• Possibility to link one calendar item to many classes or community on creation or editing
• Attach files
• Change of repeating events after creation (if you have a different repeating sequence there is no way of changing the sequence)
• Site-wide calendar for holidays
• Department-wide calendars.

Sync contacts with contact managers, palm pda's etc.

Note I see a small potential issue. Within one calendar it makes sense to color code by calendar types. When using dotLRN or otherwise aggregating calendars it makes sense to color code by calendar_id (source). It probably never makes sense to do it both ways on the same site. We may need to think this through. 

Text taken from Dirk document (2004)

Maintained by Dirk Gomez - last change on 22-Jan-2004.

I am tracking my work on calendar here. Please get in touch with me if you have comments.

Features Completed

• Separated code and presentation
• Notifications
• Removed unused or duplicated code and database queries.
• Proper use of OpenACS permissioning.

Features I am working on currently

• Code clean up
• Documentation of the data model
• CSS/XHTML

Features I will be working on

• The calendar view templates take a lot of parameters some of which require knowledge of the inner workings of the respective template: e. g. currently the calling templates passes in a url_template which determines whether an action on a particular item can be executed. I'll move this to being proper and understandable parameters like create_p or edit_p.
• New parameter Collaborative Calendar: a parameter that allows every user of a community to add, edit, and delete events if set to true.
• New parameter in DotLrn: parametrize whether to show calendar lists for a whole term.
• Allow users to store calendar preferences for example the user default view. The calendar_preferences table already exists, yet isn't used at all.
• Add a toggle: "Show all my events/Only this package's or community's events"
• Use a site-wide categories package to do away with the calendar types and the multiple calendars per package.
• Reminder - make it possible that a user sets a particular time on a calendar item to receive a reminder email
• Multi-day events
• iCal format compatible. Ideally, import/export to Outlook/iCalendar/etc.. via iCal format (by Jade)
• Ability to map any sort of date information in a database to the calendar, this means tickets, bugs, etc. perhaps via a service contract (by Jade)
• There should be any easy UI for specifying what is shown. Both the user and the admin should be able to select these things (the admin sets the range of what is possible, the user can select from those choices) (by Jade)
• Events should be able to span more than a day. Ideally, the UI for this should look good. (by Jade)
• An ability to be able to add data via the calendar as well. Anything that implements the service contract should allow you +to add information on that date as well. For example, add a ticket due that day, or add an event for that day, etc.. (by Jade)
• The calendar needs to be printable (at least for where I work - Jade)
• Desktop and Handheld support - cross-browser and cross-platform compatible (ryan-g2)
• Filters by calendar, keyword, object (e.g. Show all bug deadlines) 
• Public event submission (unauthenticated) approved by an admin (ryan-g2)
• Invite people to events (ryan-g2)
  • auto-book invitees if preference enabled, otherwise, require confirmation
  • if there is a conflict among registered users' schedules, the systems suggests possible times to the inviter.
  • people external to the system can be invited.
• Resource Scheduling - Booking (ryan-g2)
  • Schedule one resource (room, car, laptop) per calendar
  • Non-simultaneous booking (no overlapping times)
  • Book an item: suggest alternate times across multiple calendars if asset is unavailable.  Example: 5 Smart Cars for rent each have their own calendar; if all are booked from 10 - 11 AM, suggest 9-10 or 11-12 across all calendars.
  • Optional bill for booked time (connect with ecommerce module)

Data Model Suggestions

Don:
Calendar items should map arbitrary objects (perhaps only content items) to a given calendar and given acs-events. We shouldn't have to derive special types from cal item type in order to attach it to a calendar (nor should we have to duplicate content to attach it to two calendars as we do now) If we restricted the mapping to content items (i.e. calendar info some sort of content type) we could use the CR's ability to map a template to a given content type or item to make it possible for the calendar package to display calendar item details using that facility, giving the package adding something to the calendar control over how it is displayed. Much more general.

ryan-g2:
Is it possible to optionally link any acs_object to an acs_event object (event)? Examples:

• People attached to a meeting event
• Bug item attached to a deadline
• Location attached to a meeting event [google maps integration]
• Project item attached to a deadline
• Simple time and description (for booking an asset) -- unattached to an object
• Multiple objects: Rent a car C from Time A to Time B and pick it up at Location L (Event linked to two objects C and L). See zipcar.com

From above: "Use a site-wide categories package to do away with the calendar types and the multiple calendars per package."

Features I started work on

I'm listing stuff here on which I am already working, but whose completion is nowhere near finished and there is not even an estimation when it may be finished.

• Integrate libical into AOLserver
• Lift as much as possible from Brandeis' Calendar, see this forum thread

Interesting Links

• iCAL todo items via RSS
• University of Washington's Calendar Requirements Document
• Bedework calendar features

Notes

June 12, 2006 - Solution Grove worked on an AJAX calendar month view that has colors by calendar_types, has mouse overs for item details for each date, and changes months without refreshing the pages. They hope to contribute it at some point. Contact Caroline or Hamilton from Solution Grove if you need an advanced copy.

Richtext CKEditor 4

Created by Gustaf Neumann, last modified by Gustaf Neumann 25 Apr 2019, at 09:54 AM

Package Specification Summary for Package: richtext-ckeditor4

Bug Tracker Summary for Package: richtext-ckeditor4

There is no package with the name "richtext-ckeditor4" known to bug-tracker.

Code Metrics Summary for Package: richtext-ckeditor4

In general, the CKEditor can be used via CDN (zero configuration, default) or via local files. One can use /acs-admin/ (section "Site-wide Service Administration" to download a version to your local site to reduce latency or to use local modifications. By default, the "standard" preset is downloaded. By altering the variable "ck_package" in packages/richtext-ckeditor4/tcl/richtext-procs, one can download other presets as well (see https://ckeditor.com/presets-all).

The CKEditor widget can be used at least in two scenarios: (a) as a richtext-widget or (b) within xowiki as a class of a form-field.

• (a) Here is an example for the use of the richtext widget configured for ckeditor4, showing some options:

      text:richtext(richtext),nospell,optional 
      {label "CKEditor"}
      {html {rows 15 cols 50}}
      {options {
          editor ckeditor4
          plugins wsc
          extraAllowedContent "u;span{color}"}
      }
  

  This minimal example should work with the "standard" distribution of CKEditor and adds the "wsc" (Web Spell Checker) plugin, and allows the tag <u>u and <span style="color:...">...</span> to be used in the content. Otherwise, these flags are removed by the context filter of the editor (for details, see CKEditor documentation). Additional "options" are "skin" and "customConfig", where the latter refers to a JavaScript file which can be used for detailed configuration (for more details, see https://docs.ckeditor.com/#!/guide/dev_configuration).
  
  Note, that the usual constraints for richtext widgets holds like for all other richtext implementations (e.g. the editor will only be activated, if UseHtmlAreaForRichtextP is set to true).

• (b) when used as a form-field within xowiki forms, there are detailed config options available: mode, displayMode, skin, toolbar, CSSclass, uiColor, allowedContent, customConfig, extraPlugins, extraAllowedContent, templatesFiles, templates, contentsCss, imageSelectorDialog, and additionalConfigOptions. A short introduction to form-fields is in http://alice.wu-wien.ac.at:8000/xowiki-doc/#forms. One should set the PreferredRichtextEditor (xowiki global parameter) to ckeditor4.

Boomerang Plugin

Created by Gustaf Neumann, last modified by Gustaf Neumann 11 Jan 2018, at 01:41 PM

Package Specification Summary for Package: boomerang

Bug Tracker Summary for Package: boomerang

There is no package with the name "boomerang" known to bug-tracker.

Code Metrics Summary for Package: boomerang

Integration of the Boomerang library as an OpenACS Plugin

Boomerang is a JavaScript library to measure the performance of your website from your end user’s point of view. It has the ability to send performance data measured at the client back to the server via a beacon URL further analysis.  The boomerang library implements Real User Measurement (RUM) to measure the performance experience of real users by collecting quality indicators from the clients.

The boomerang library is released under the BSD license.

Details:
    https://soasta.github.io/boomerang/doc/

This package integrates boomerang with OpenACS, in particular with OpenACS subsites.

Features

• Obtain client site timings to measures the performance of your  website from your end user's point of view.
• Support sampling (e.g. just obtain metrics from every nth request)
• Output performance data in a format suitable for feeding into  Elasticsearch/Logstash (see below for example config files)
• Configure the appearance of the boomerang per subsite with  the following parameters:
   

  BoomerangEnabled	0|1
  BoomerangSample	1
  BoomerangBeaconUrl	/boomerang_handler

   
  The parameter BoomerangSample can be used for busy sites to sample not every request (when the value is 1), but e.g. every 5th request (setting BoomerangSample to 5).
• Support for host-node-mapped subsites
• Site-wide admin support for compressing .js file
• Performance: include boomerang in the template costs about 0.3ms, processing of the beacon call takes about 1ms (filter times).

Installation

1. Install this package via the OpenACS Package Manager
    
2.  Add this package to the templating system
    
   • OpenACS 5.10.0d2 or newer:
     The boomerang plugin uses the "subsite::page_plugin" callback, so no changes on templates are necessary. Make sure to update as well the acs-bootstrap-installer to 5.10.0d2 or newer to obtain the updated blank-master.
      
   • OpenACS 5.9.1:
     Add to the top of your blank-master.tcl the following snippet:

           if {[info commands ::boomerang::initialize_widget] ne ""} {
               ::boomerang::initialize_widget
           }

3.  Configure in the parameters of the subsite (e.g. the main subsite) the section "Boomerang Plugin"

Usage

For the explanation of the parameters, see:
     https://soasta.github.io/boomerang/doc/howtos/howto-0.html
     https://soasta.github.io/boomerang/doc/api/RT.html
     https://soasta.github.io/boomerang/doc/api/navtiming.html    
 

Prerequirements

The implementation uses nx from the next-scripting framework.

    https://next-scripting.org/xowiki/

which is automatically installed for XOTcl2 via naviserver-openacs. It works best with OpenACS 5.10.0d2 or newer, but works as well with 5.9.1 (see INSTALLATION section above) or earlier versions with little adaptions

OPTIONAL: Define a custom Boomerang Plugin

1. Clone boomerang repository
2. Install npm, grunt if necessary
3. Follow step 2 in https://github.com/SOASTA/boomerang     which means
         ... configure plugins
         ... grunt clean build
4. The result is in the build directory. The generated files have the a build-time stamp in seconds included. You might which to rename these with a custom name.
5. Copy the the *.min.js and *.min.js.gz files to the boomerang/www/resouces directory, which might be

   cp  build/boomerang-1.0.*.min.js build/boomerang-1.0.*.min.js.gz ..

   and adapt the version number in the boomerang parameters (on /acs-subsite)
    

    

OPTIONAL: Feed Boomerang Data into an elasticsearch cluster

When boomerang is enabled, the results of the beacon are placed into
the OpenACS log directory with a name boomerang-*.log (containing the date).

Below are sample-snippets from OpenACS.org the log-files into elasticsearch,
such that it can be analyzed later with kibana or grafana.

Example filebeat entry for the data feed:

      paths:
        - /var/www/openacs.org/log/boomerang-*.log
      input_type: log
      fields:
          log_type: boomerang-log

Example logststash entry (input filter for transforming the data from filebeat and to feed it into easticsearch)

  if [fields][log_type] == "boomerang-log" {
    json {
       source => "message"
       remove_field => [ "restiming" ]
    }
    grok {
       match => [ "source", "/var/www/%{GREEDYDATA:server}/log/boomerang-" ]
    }    
    geoip { source => "clientip" }
  }

Example Analysis Screenshots from OpenACS

The following chart shows performance indicators of OpenACS.org over the last two days. The topmost chart is produced with grafana and shows elapsed time (left axis) and number of requests (right axis). "Average runtime" is the time measured on the server (how long does it take the server to fulfill the requests), whereas "Average t_done" is the time it took the browser to render the page (stating at the click). "t_done" is a default measurement provided by boomerang. Note, that the values from boomerang require that JavaScript is active at the client side (i.e. there are typically no spiders included in this value, as well only views).

We can see from these values that the average runtime is 36ms, while the full render time is on average 2.2s (about 60x larger). One reason is that static content is served quite fast.  The second chart is as well produced with grafana and analyses the phases of requests based on W3C Navigation Timing. The nt_response_time shows the client point of view how long it took the server to provide an response to the request.

We can see that nt_response_time is about 100ms (it takes longer to server the dynamic html files). Also from this point of view the response time of the server for the main request only contributed a fraction of the total time. The longest time is the processing time in the client, which depends on the content, CSS, JavaScript, etc. Note that these are overall values, averaging over all requests. One can certainly drill down on certain pages for more details.

Another interesting aspect is the geographic location: has the client a good internet connection in respect to the server? The first map was produced with kibana and shows from which geographic locations pages of OpenACS.org were requested over the last week. Locations with more requests are shown emphasized.

We see that the highest number of requests are coming from the US (Seattle and Washington areas), and in Europe is Austria (Vienna) and France (Paris) issued many requests. If we analyze for boomerang requests with high values of "t_done", we see that these requests are coming from regions far away from Vienna, where the server is located (e.g. from Asia, South America, Australia)