Developer meeting February 2008 meeting minutes

From Dokeos

Jump to: navigation, search

Contents

Dokeos LCMS progress (since December 2007)

Hans starts with an overview of all changes to the LCMS code since December 2007.

  • in the future, Dokeos 2.0, will only work with a single database setup. We dropped the multiple database possibility.

It is easier to maintain only one database setup.

  • the installation procedure has been completely rewritten. It follows the Dokeos 2.0 philosophy now. It uses the single database setup and some build-in checks to control the installation procedure. If something goes wrong the installation is aborted. For the moment the installation takes some

time to complete. We need to improve the code to make some performance changes. Attention! Change your max_execution_time on your server for the moment. The default (30 seconds) is not enough.

  • the configuration settings framework has been rewritten completely. Where the settings were in flat files in the past they are now stored in the database.

There is a general set of classes available to store and retrieve the settings. The function api_get_setting() has now completely been removed from the code. It took quite some time to achieve that. In the future we would like to enhance that system and parse an XML file during the LCMS installation with default configuration settings. For the moment we have 20 settings. We can think of at least 30 more settings.

  • Condition Framework. A new translator function is created and all condition functions are moved from the application datamanagers to the central

condition framework class.

  • the function api_get_path is now completely replaced with a new Path class.
  • Platform session class, new class that deals with registration, retrieval and cleanup of session variables. There used to be some problems

with the usage of sessions in the old Dokeos code. This will be a lot less in Dokeos 2.0 since everything is now retrieved by classes and corresponding objects.

The result of all this work will be the removal of the old dokeos "main" folder. Hans is looking into some last unchecked files for functions and useful functionality. He hopes this work is finished in a few weeks.

The big topics that remain now to complete the Dokeos 2.0 kernel:

  • roles and permissions system
  • tracking framework

Normally Hans would already have started with the roles and permission system but cleaning up the old dokeos code took quite some time. We will benefit a lot in the future from the efforts that are now made. Making use of all the classes provides us with lots of flexibility.

For example the export class, an abstract class with extensions like PDF, CSV and XML. If somebody wants to implement a new export mode he/she only has to extend the abstract export class. No kernel code is to be touched!

Another advantage is that all functionality is now grouped together in classes. In Dokeos 1.8.5 course functions are spread around different folders and libraries. In Dokeos 2.0 that is nicely grouped together.

We can conclude that Hans delivered a very good job already! Keep up the good work!

LCMS Shibboleth integration

The University of Geneva worked on a Shibboleth intergation. The code is currently working on their local server and needs to be committed to the SVN. Patrick has some questions for the community involving their efforts.

1) Where to place to code? 2) Do we keep the inc.php files with the authentication server, username and password? Or are there other proposals? 3) We need to change the index.php file to work with the Shibboleth authentication. Are there recommendations on that?

1) All code needs to be placed in /common/authentication/. It has to extend the general authentication class. 2) We are very much in favour of webadjustable settings that can be modified through the admin interface. We would like to have one page where the administrator can activate/desactivate authentication methods. On that page the corresponding credentials (servernames, usernames, passwords) can be viewed/updated/saved. 3) Since multiple authentication methods can be active at the same time we need a cascading login system that checks the user credentials against all active authentication methods. If the users does not exist in the system yet his account can/must be created (this must be a setting of course).

LCMS forum/wiki implementation

The University of Geneva has some development time/power for the LCMS project. The student will start from the beginning of March and will work on the implementation of the forum. There are some missing functions (different views, .. )

Another person from Switzerland is interested to work on WIKI integration. Patrick asks for feedback on that subject.

  • LCMS has already classes avaible for comparing two learning objects
  • LCMS has already classes avaible for version management of learning objects

Please use those classes! They are already used in the repository!

  • there is a need for a WIKI module in Dokeos.
  • if the WIKI is build up like other learning objects, for example "a wiki page is a learning object", we can publish wiki pages in other applications too.

We look forward to see the Geneva contributions! Please communicate about this topic with the community as much as possible.

LCMS migration

Hogeschool Gent has two internship students that will work on the migration framework the next three months. The two students (Sven/David) explain their proposal to the community. The goal is to build a framework around a main migration controller. That main controller will work with abstract classes like:

  • import_users
  • import_classes
  • import_courses

After the abstract classes are build we can extend them for each platform we want to migrate. The students will extend the classes so we can migrate from Dokeos 1.8.5. But everybody can extend those classes to migrate from eg. Blackboard, Moodle, .. That way we have a general migration framework available for the future.

There are some issues already:

  • ownership of learning objects (analysis has to be made)
  • orphan learning objects (analysis has to be made)
  • missing functionality in the LCMS

We need a set of cascading ownership rules that are used during the migration. The students will communicate their analysis on the forum and mailing list. More news on the migration tool and hopefully a working demo in the next community meeting.

LCMS Languages

We would like a general clean up of the languages when we release Dokeos 2.0. Hans explains the proposals.

An alternative way to retrieve language strings would be to make the system array based. Retrieving a string would then become checking for key existance to retrieve that particular variable. The language files would be included at the start of script execution. 

$lang['weblcms']['Actions'] = 'Bewerkingen';
$lang['weblcms']['AddAttachments'] = 'Bijlagen toevoegen';
$lang['weblcms']['Amount'] = 'Aantal';
$lang['weblcms']['AnnouncementToolTitle'] = 'Aankondigingen';
$lang['weblcms']['Attachments'] = 'Bijlagen';
$lang['weblcms']['BrowserTitle'] = 'Bladeren';
$lang['weblcms']['By'] = 'door';
$lang['weblcms']['CalendarToolTitle'] = 'Agenda';
$lang['weblcms']['Category'] = 'Categorie';

A benchmark revealed it takes a simple test-script about 140 ms to retrieve 40 variables out of a list of 10.000 in the current system. The proposal is already tested. Testing parameters were identical to the ones mentioned above. (10.000 variables, 40 retrievals).

  • It took the test-script 11 ms to retrieve all strings. (as opposed to the current system's 140 ms)
  • Memory usage was 1240 kb (as opposed to the current system's 1279 kb)

We see no real disadvantages not to implement the array based system. If Hogeschool Gent has some extra time to will start packing the language files in seperate application packs.

Their will be some changes needed to the DLTT system. Users must have to ability to start a new language application pack. When strings to existing application packs are added the system has to check if the strings are not already present. That way we hope to avoid double, tripples.

The moment we start packing the languages in applications packs we should filter those doubles. An effort from all translators will be needed so we can release the LCMS system with at least a dozen complete languages.

Another advantage of working with application language packs is that the kernel code of Dokeos 2.0 will be smaller and therefore easier to translate completely.

LCMS CSS and images

There is a new lay-out folder in Dokeos 2.0 where all images and CSS files will be stored. When moving them a general cleanup is needed. The idea is to work with a small default kernel CSS and all the other applications can have their own CSS extensions.

The LCMS system should also have a style switcher available so an institution can load its own style (template) to the system without modifying the default.css file. A lot of websystems offer the possibility to upload a template pack and use the new style right away.

There will be a general image folder and subfolders for other applications. This split will offer a more readable code and file structure.

Dokeos 1.8.5 debug session

Hogeschool Gent organises for the first time a debug session. Goal is the detect and fix bugs in Dokeos 1.8.5. The session start on 1/March and ends 1/May. There are 4 groups each testing other modules/tools.

We offer them a seperate testplatform were they are all course administrator. We work with two different groups:

  • Bachelor IT students: detecting and fixing bugs
  • postgraduate IT students: coaching the IT students, communication between HoGent test results and Dokeos company.

The students are rewarded at the end of the debug session (first price is a portable for example) If the project is evaluated positively we would like to organise it worldwide next year. We hope that other institutions are inspired by the HoGent initiative to cooperate in this or similar projects.

Dokeos Community Building

We discuss about ways to organise the Dokeos community and how to enlarge the development team. The biggest problem is money. Our institutions don't have enough money to contract new developers. Another problem is that we have people enough but everybody is very busy with his own dokeos installation. So we need to find people/money somewhere else.

We focus on two paths:

  • enlarging the community
  • funding

Enlarging the community

  • organise internships with students. (very succesful in the past)
  • communicate more on the projects that we are working on (blogging system)
  • organise a "community building" session on the users day in Geneva
  • merge with other development teams (like Claroline)
  • use flashmeetings so the whole world can connect to our meetings
  • invite spain/netherlands/italy on the next meeting (flash meeting)
  • start community website - blog system (with advertisements to pay the hosting costs)

Funding

  • european funds
  • projects like 'google summer of code'

We hope that everybody puts some effort, time and energy in the community building.

TODO

We conclude with a todo list for the next community meeting (end of April 2008).

  • collect information about funding projects (everybody)
  • collect information about the community: who, where, what, .. (everybody)
  • look for a flashmeeting setup (Thijs)
  • create SVN account for Geneva (Stefaan)
  • arrange meeting with Thomas to inform us about the community (Thijs, Stefaan)
Retrieved from "http://www.dokeos.com/wiki/index.php/Developer_meeting_February_2008_meeting_minutes"
Personal tools