Technical Elements and Interoperability - Profile2 Dry Run

Owned by Former user (Deleted)
Last updated: Nov 24, 2009 by Former user (Deleted)Version comment
5 min read

General Technical:

  • What kind of project is this?
    Profile2 is a drop in replacement for the original Profile tool. It shares the same backend for persisting the user profile information, following the SakaiPerson API in Common. The SakaiPerson API has been changed in trunk already, to cater for more fields in the model that Profile2 uses. This does not affect the original Profile tool at all. Additional services have been created to persist other information like connections and status updates.
  • What level of code review has been applied?
    Most of the service layer code was reviewed when the EntityBroker services were added in, because the API's needed to be moved around and split up a bit. This was done only by the developer though. More eyes on this would be really appreciated.
  • What architectural or technical documentation exists?
    Sakai wiki page for the Profile2 project including install guide, configuration settings and everything else
    JIRA has been used to track all tasks and bugs from release 0.9 onwards
  • How many people have been working through the code?
    Steve Swinsburg, formerly of Lancaster University UK, now at ANU Australia, and Adrian Fish, Lancaster University, UK.
  • What is the lifetime of the code? How long has this code been around?
    First SVN checkin was at r53348 on 23rd September 2008. Confluence space was created around January 2009 when documentation was gathered, ready for the first release. Release dates are documented in Confluence and also in the Jira roadmap.
  • How long and where has been it in production?
    Lancaster University has been running the tool in production since early releases in January/February. I have heard of, but not confirmed, other institutions running it, possibly in production. This should go to the list so see who is using it.
  • Is the project planning on independent releases?
    Profile2 is on an independent release cycle. The current version is 1.2.1. This version is available in Sakai's contrib subversion repository https://source.sakaiproject.org/contrib/profile2/tags/1.2.1/
    Version 1.3 will be a dual binary/source release in line with other projects on independent release cycles.
  • What happens if an instance uses, then uninstalls the project?
    The current version of Profile2 (up to 1.2.1) works side-by-side with the existing Profile tool. Because data is only added to and not changed, the existing profile will continue to work if it is rolled back.
    There is a conversion utility in Profile2 that can be run at startup that will convert any images stored in the SakaiPerson JPEG_PHOTO column, into ContentHosting resources and the appropriate links made to add this image to Profile2, however the JPEG_PHOTO column is left untouched. All other data is stored in PROFILE_* prefixed tables in the database.
    Starting with version 1.3, the legacy ProfileManager API is being imported into Profile2 so that existing tools that use the Profile data, eg Roster, can get their data from Profile2 without being modified. This will mean the existing Profile will lno longer function, when Profile2 is installed as the legacy ProfileManager API will be overwritten with the modified one. If one wanted to revert to using the original Profile, they would need to redeploy the ProfileManager API from the original Profile tool (although this would happen when the tool was built and deployed anyway).

Code Maintenance / Metrics:

  • How large is the project? (Lines of code / modules) http://cloc.sourceforge.net v 1.08 T=1.0 s (213.0 files/s, 27209.0 lines/s)

    Language

    files

    blank

    comment

    code

    scale

    3rd gen. equiv

    Java

    100

    3698

    4512

    9561

    x 1.36

    13002.96

    XML

    35

    366

    243

    2249

    x 1.90

    4273.10

    HTML

    42

    625

    207

    1505

    x 1.90

    2859.50

    CSS

    4

    207

    64

    1061

    x 1.00

    1061.00

    Javascript

    8

    116

    550

    1021

    x 1.48

    1511.08

    SQL

    24

    193

    68

    963

    x 2.29

    2205.27

    SUM:

    213

    5205

    5644

    16360

    x 1.52

    24912.91
  • How many non-kernel Sakai dependencies?
    Common, EntityBroker 1.3.6+, TinyUrlService
  • How many non-Sakai dependencies?
    Apache Wicket 1.3.6
    Apache Wicket Extensions 1.3.6
    Apache Wicket Spring 1.3.6
    Apache Wicket Spring Annotations 1.3.6
    Apache Wicket TinyMCE 1.3
    Log4J 1.4.2
    SLF4J 1.4.2
    Twitter4J 1.1.7
    Jasypt 1.5
    ICU4J 3.8
    Commons Lang 2.4

All available from a Maven repo nearest to you.

  • Are there core dependencies on libraries not typically used in Sakai?
    Apache Wicket mainly, although its use is becoming more common in Sakai. Other libraries listed above are for Twitter and encryption
  • How tightly coupled is your tool with non-Sakai dependencies?
    The above dependencies are essential.
  • What is the persistence mechanism?
    It is the same as in the existing Profile model. It uses Hibernate.
  • Any known JVM version dependencies preventing or forcing a Java 6 or Tomcat 6 upgrade?
    I have been using Java 1.6 since late 2008, no issues. Tomcat 6 should be fine as well so long as everything is deploying in the right spot by the Sakai Maven plugin.
  • Are there automated tests?
    No, although these will eventually be done. There are no automated integration tests currently to demonstrate interaction with Sakai as a whole.
  • Are changes logged?
    Yes, see Jira: http://jira.sakaiproject.org/browse/PRFL
  • Is the documentation up to date with the tool?
    Yes and its very comprehensive. See Confluence http://confluence.sakaiproject.org/display/PROFILE/Profile2
  • Are there kernel changes required to support the project?
    No, the changes have already been made in Common trunk with no impact to any existing service whatsoever.

Production Setup / Maintenance:

  • Are there any conversions, migrations or other administrative preparations required in order to start using the tool?
    There is a conversion utility to convert out the image stored in the database table into ContentHosting for use in Profile2. This is not essential to run, people will just need to upload their image if they had one. Images in the original Profile tool were near impossible to add by a user unless they already had one uploaded somewhere so this might not be an issue. Existing institutional photos are not yet supported.
  • Is there required configuration or does it work out of the box?
    There are a number of sakai.properties you can use to control Profile2 at an installation level, none are essential though. See Confluence for the list.
  • Can complex or objectionable features be disabled?
    Yes, almost everything can be locked down or disabled if you desire. Again, see Confluence for the list of properties. For items that cannot currently be disabled/locked, they soon will be able to be controlled in this way.
  • Does this tool depend on a file storage mechanism other than Content Hosting?
    No.
  • Are there any special requirements for deploying this project in a cluster? For example, does this project assume JGroups, shared network storage, UDP multicasting, or Terracotta server.
    No.
  • Was load testing performed? What were the results? Is a load testing report available?
    No formal load testing however test were performed on 4000 dummy user accounts, performing searches and adding people as friends, load results and memory use was fine. There is a Jira ticket to allow Profiles to be searched via the Sakai Search ,this will improve search results even further. Note that his will be limited to Profile2 search since there are Privacy filters that need to be employed depending on who you are and what info you can see about a person.
  • Are there features that are database intensive, either in terms of large data or heavy CPU demand?
    Not that I am aware of.

Interoperability:

  • Does any other Sakai tool or service depend on this functionality?
    Roster depends on the legacy ProfileManager which is being pulled into Profile2 to give it it's data.
  • Are there overlaps in functionality with other tools or services? Overlaps with standard Profile although with a richer feature set and improved interface.
  • Is content created within sites? If so, are archive, import, search and duplicate features implemented?
    No, the content is per user. Search is built in to Profile2 and import/export is already in Jira as a task.
  • Are there any data feeds (RSS, XML, JSON) exposed via the Entity broker, sdata, or a one-off implementation?
    Yes, see EntityBroker support for Profile2
  • Does the work implement particular notable standards?
    No. But the import/export will.

Time tracking
Started: 10.20pm 11/11/09
Stopped: 10.45pm 11/11/09 - the baby calls!
Started: 11:30pm 11/11/09
Finished: 12:20am 12/11/09