The OpenACS Directory

Created by Gustaf Neumann, last modified by Benjamin Brink 29 Jun 2017, at 04:35 AM

See: The OpenACS Directory

OCT Meetings

Created by Dave Bauer, last modified by Benjamin Brink 29 Jun 2017, at 04:34 AM

See Also: openacs-release-status openacs-todo

Next Meeting: 2010-04-28 18:00 CET/CEST Convert to your local time

Agenda

• Next OCT Election (May 2010)
• OpenACS 5.6 Release Beta Weekend 2010-04-25

Previous Meetings

• 2010-04-21 Minutes
• 2010-03-17 Minutes
• 2010-03-10 Minutes
• 2010-02-24 Minutes
• 2009-09-30 Minutes
• 2009-09-23 Minutes
• 2009-09-16 Minutes
• 2009-09-09 Minutes
•  
• 2009-03-11 Minutes
• 2009-03-04 Minutes
• 2009-02-25 Minutes
• 2009-02-18 Minutes
• 2009-02-11 Minutes
•  
• 2009-01-28 Minutes
• 2009-01-21 Minutes
• 2009-01-14 Minutes

2008

•  
• 2008-06-25 irc log
• 2008-06-18 irc log
• 2008-06-11 irc log
• 2008-06-04 irc log
• 2008-05-28 irc log
• 2008-05-14 irc log
• 2008-05-07 irc log
• 2008-04-30 irc log
• 2008-04-23 irc log
• 2008-04-16 Minutes ( irc log)
• 2008-04-02 Minutes ( irc log)
• 2008-03-12 Minutes ( irc log)
• 2008-03-05 Minutes ( irc log)
• 2008-02-27 Minutes ( irc log)

2007-02-07 Summary

Created by Rocael Hernández Rizzardini, last modified by Benjamin Brink 29 Jun 2017, at 04:32 AM

Agenda:

1. Zen vs. acs-core
1.1. Site master template will have to be changed to be compatible with package changes for zen
In particular content pages need to be wrapped in <div class="main"> (or id= or something)
Solution: we do <div class="main"><slave></div>

1.2. CSS

Don propose we duplicate CSS at the moment rather than try to integrate .lrn zen theme css and core - our schedule's tight as tight can be and this would be faster
Someone has to do it (next meeting we'll determine who does what and probably the overall work plan)
Change to be done in oacs-5-3.
Sharing a single css file comes for 5.4

2. oacs 5.3.1 release
2.1. The zen work above
2.2. Greek translations
2.3. Nothing more other than critical bug fixes that hopefully are well-tested
2.4 Target date: 1st. march alpha.
2.5. NOTICE: people who upgrade existing sites will have to change their layout! To what extent is something we have to figure out in the next OCT meeting.
2.6. To work on the layout enhancements:
check this page:
signup for something
contact: honchos@dotlrn.org  which is the people leading the effort.
.lrn mtg every tuesday at 1700 GMT
2.7. We don't have time to deal with UI clean-up for 5.3.1

Present: lee, don, dave, roc.

Permissions explored, a practical way exists

Created by openacs irc community, last modified by Benjamin Brink 29 Jun 2017, at 04:31 AM

This is from a discussion about permissions on OpenACS' irc (names changed) that took place sometime circa 2005.

ryan: How do I create a group containing other groups? 
dave: composition_rel 
ryan: For instance, I have 30 admin groups, and instead of adding user A to each one manually, I want to add her to one group, and thus all 30. 
dave: what are you trying to accomplish? 
dave: you can't do that 
ryan: crap. 
dave: it it totally non-intuitive 
dave: here is why :) 
dave: we have the Super Admin group 
dave: wait. dave: no it doesn't work 
ryan: So what is a composition_rel? I thought parties were supposed to be a super-set of groups. 
dave: let me explain :) 
dave: no 
ryan: ok, thanks :) 
dave: here is how it works. 
dave: Super Admin 
dave: then we have admins_a which is a component of super admins 
dave: maybe it can work. 
dave: question is dave: can a group dave: have a composition_rel to more than one other group 
ryan: So what is the definition of a component? 
dave: lets find out. 
dave: a component 
dave: so if Admin A is a component of Super Admin 
dave: then every member of A is a member of Super 
dave: which is NOT what you want. 
dave: you want ever member of super to have permission over all the groups "inside" it right? 
dave: but in this case every member of A would have permission over all the other components etc. 
dave: group are NOT for permissions. 
dave: that is the design weirdness 
ryan: huh? 
ryan: Now I am completely confused. 
dave: you can't use groups the way you want 
ryan: isn't the whole point of groups to avoid permissioning on individual users? 
jim: but you should be able to build a page that asks for a user and puts the user into the 30 groups 
dave: ryan, yes. 
dave: you they don't inherit the way you think 
ryan: so you set permissions on a group with a set of objects, then just add/remove users from the group, right? 
dave: its backwards to what you are thinking. 
dave: yes dave: that works 
dave: perfectly 
jim: so you can get what you want (convenience, non-tedium) but have to do it another way 
dave: but composition_rels dave: behave backwards 
dave: they are not useful for org chart models 
ryan: ah ok. 
dave: but I think it can work 
ryan: What is an application of composition_rels? 
dave: here is what you would do 
dave: if it works 
dave: create all your groups 
dave: Admin A, Admin B etc 
ryan: done. 
dave: then make one group 
dave: and give it a composition rel to all of those groups. 
dave: its upside down. 
dave: then if I am in the one group, i am in all of those other groups 
jim: so you're putting the one group into all the groups 
jim: that should work :) 
dave: yes d
ave: b/c its not _in_ 
dave: its a component. d
ave: i think that will trigger the correct permissions. 
ryan: how do components work in the data model - I want to understand this better. 
dave: well jim: it' dave: then I recommend you 1) read the acs-kenrel sql files 
jim: s a special kind of acs_rel 
dave: 2) run alot fo experiments in psql 
dave: 3) find a bug in the triggers 
dave: :) 
dave: that is how I figured it out. 
dave: sucks huh. 
dave: seriously the comments in the SQL files in acs-kernel are very illuminating. 
dave: also have you read permissions tediously explained? 
ryan: but you're it'll work? ryan: Yes. d
ave: i am not sure it'll work 
dave: but jim: we think it will work r
yan: but I could re-read it a fourth time 
dave: i don't see any rule 
dave: that disallows a group being a component of more than one group 
dave: if there is such a rule, it won't work. 
ryan: but compositions typically extend 'up' the chain of groups? 
dave: yes dave: that is what its for 
dave: so for example 
ryan: what is a practical example? 
dave: I have Main Subsite 
dave: and several other subsites 
dave: wait 
dave: actually this is an example of why it doesn't work :) 
dave: hmmm actually I have to check 
dave: not sure if susbsite groups are components of main subsite or not. 
dave: .... 
ryan: You see, I want to create this super group and then let the client admin the members... 
dave: ok there are no rel_constraints on a default install. so that should be safe. 
dave: yes d
ave: but its really a sub-group 
jim: try it with two groups and another group be a component of both groups... give each of the first two groups two different permissions... put a user into the component group... 
dave: a super group would not work the way you want. 
dave: here i what you do 
jim: see if the user has both perms 
dave: 1) create two groups 
dave: 2) create another group 
dave: 3) make the third group a component of the first two 
dave: 4) add someone to the third group 
dave: 5) check if they are a member of 1 and 2 
dave: for extra credit 
dave: apply a permission to 1 and 2 
dave: check if the members of 3 have permission on those things 
dave: if this works 
jim: 1-4 and the extra credit are what I just sed :) 
dave: i just solved the oldest OpenACS 4 riddle 
joe: As a topical aside, we changed the way we use groups in our subsites for dotcommunity. One for admins and one for members (so we don't use admin_rels). Then we use a composition rel to make admins of top level sites also admins of lower level sites, and to compositions in the opposite direction to make members of lower level sites members of the higher level ones too. 
dave: jim, yes :) 
jim: 5 is a good idea too 
ryan: ok, sounds good. Will test and get back to you. That would be very cool if it could work both ways. Obviously it is important to be able to have groups of groups... 
dave: joie: you could still use admin_rels to do that 
dave: it would work the same way. 
dave: ryan, yes if that works the way I expect it would be cool. 
dave: joie, so is the lower level admin group a component of the higher level admin group? 
joe: The problem with admin rels was that an admin of a subsite became an admin of the supersite, which isnt what we wanted. 
dave: or the other way around? 
dave: joie: yes dave: that is what I just said 
dave: the component rels go the wrong way 
dave: than what you would think intuitively 
dave: although mathematically they work correctly as specified. 
dave: damn PhDs 
dave: basically we need to write high-level functional wrappers over all this crap 
joe: So we have a composition rel going "down" for admins, and "up" for members. So the supersite admin group is a component of the subsite's admin group, and the subsite's members group is a component of the supersites members group. 
dave: so you can just call a tcl proc that tells you what happens (instead of what is does in the database) dave: joie: ah so it _does_ work. that is just what I told ryan-g to do 
dave: we need to write a tcl api to do that that is clear what is happening. 
jim: so members of the subsite become also members of the supersite 
dave: yes dave: which makes sense 
joe: Indeed. Then we frigged the acs-subsite members pages to do the "right thing". 
dave: but then admins of the subsite become admins of the supersite (if you use admin_rels) 
dave: which is why you don't want to do that. 
dave: joie: but you are right 
dave: and openacs is wrong 
dave: except I doubt there is an upgrade script that would work 
dave: damn PhDs 
dave: joie: 
why the hell didn't you tell us this before? :) 
dave: i have been trying to figure that out for 4 years 
joe: We have an upgrade script that does it somewhere. Rob wrote it. 
dave: you rock. 
joe: We weren't sure the new way was "right". 
dave: yeah dave: it is dave: b/c it makes sense dave: well 
dave: except dave: no its right. 
joe: We then got rid of admin_rels completely. 
joe: and only use membership_rels 
dave: b/c everyone expects it to work that way 
dave: yeah see 
dave: the problems is 
dave: all this stuff was experimental 
dave: and no one every finished it jim: you would need to be careful when deleting certain objects 
dave: except you did. 
dave: so now we can say "this is the way its supposed to work' We can say that because that is the way every one has expected it to work, but it never did 
dave: wow 
jim: make sure to remove all rels first then delete 
dave: i am so surprised. 
joe: The code is in the dotCommiunity download on www.dotcommunity.org. The upgrade scripts aren't there though. 
dave: this is so cool. 
dave: get them! 
dave: :) 
joe: Heh. I'll talk to Rob about it tomorrow, as not sure what he implemented.

News

Created by Robert Taylor, last modified by Benjamin Brink 29 Jun 2017, at 04:28 AM

See: OpenACS News Section

(Sketch for) OpenACS Home

Created by Dave Bauer, last modified by Benjamin Brink 29 Jun 2017, at 04:20 AM

OpenACS (Open Architecture Community System) is a toolkit for building scalable, community-oriented web applications. OpenACS is the foundation for many products and websites, including the .LRN e-learning platform. OpenACS is open source and is available under the GNU General Public License.

Why use OpenACS?

OpenACS is unique in the breadth of services it offers developers and administrators. Millions of dollars and decades of developer time have gone into the maturation of OpenACS.

You can read the technical reasons to use OpenACS.

How do I install OpenACS?

The installation documentation contains all the necessary steps to install OpenACS on a large variety of systems. There is also a Windows Installer and other packaged installations openacs-system-install. Also Check the installation requirements before installing. The current stable release is OpenACS 5.9.0 (cvs aliases).

How do I work with OpenACS?

You can start by reading the documentation, specifically tips on customizing, the developer's tutorial, and
the FAQs. There is a OpenACS Wiki and a list of packages that extend OpenACS.

For professional help, contact one of the OpenACS companies.

OpenACS Community

One of the strengths of the OpenACS project is the community surrounding it:

• Discussion forums
• Blog
• IRC at irc://irc.freenode.net/#openacs
• Chatroom logs and today's log
• File Storage
• How to contribute
• Test servers
• CVS Browsers options: Browser, https://github.com/openacs
• Technical Decisions on the direction of OpenACS, made by the community-elected OpenACS Core Team.

News

Recent Posts

{legacy} Proposed project goals

Created by Robert Taylor, last modified by Benjamin Brink 29 Jun 2017, at 04:18 AM

This page remains for legacy discussion.

This is regarding Approach 1. in en:Documentation_Project_Discussion. The milestones are performance based, instead of directly connected to work, which makes them an impractical plan to follow.

Overview: 

Here are a few things we are working to accomplish with XoWiki and the OpenACS website:

Milestones:

MILESTONE I:  Tooling Up - Before We Can Accomplish Anything We Must Have a Powerfull Wiki.

- XoWiki is functional for the most part

- a few bugs and feature requests remain, Gustaf and Dave have rocked the OACS boat and created some amazing functionality in a short period of time.  When some of these items are cleared this Milestone will be considered accomplished.
 

MILESTONE II:  Testing Packages after each OACS release.

- XoWiki is functional, we can start testing immediately.  Look for a TESTING PROCESS document in the PACKAGES category (if it's not up now, soon).

 
MILESTONE III: Look and Feel vs. Content

- XoWiki is turning out to be very powerfull and easy to use.  We will need to focus on content first, look and feel can be handled later.  UTILITY has a greater priority over LICKABILITY.

MILESTONE IV: Fanatical Documenation.

- API documenation will stay as is.

- see en:Documentation_Project

MILESTONE V: New Blood.

- I think we can start attracting new devs as soon as our Documentation allows a new developer easy egress into the toolkit.  Watching Dave, Gustaf and others litterally create new functionality out of thin air over the last week of January 2K6 is clear indication the barrier to entry is not the toolkit, it is with the resources and tools they need to be able to understand and become developers. 

- I think getting a LICKABLE look and feel is something that can be done simultaneously, at a stage after XoWiki has been thoroughly debugged and tested.

2006 Session 1: Towards full Accessibility in LMS

Created by Olga C. Santos, last modified by Benjamin Brink 29 Jun 2017, at 04:11 AM

Overview:

Accessibility status in .LRN

Objectives:

1. Analyze the accessibility status of .LRN/OpenACS and discuss the existing main problems and the way to solve them.
2. On-going developments and research works on accessibility compliance in LMS
3. Educate .LRN community in the importance of developing with accessibility requirements in mind
4. Define some guidelines to help .LRN developments reach the accessibility requirements
 

Scheduling:

Keynote: Accessibility in Community and Open Source Software Developments: the Moodle perspective

Martyn Cooper - Head of Accessible Educational Media team at the Open University in the UK

Among diverse research and internal consultancy roles Martyn Cooper has overall responsibility for accessibility in the Open University's VLE which is based on Moodle.  The Open University has nearly 10,000 disabled students and takes its legal and moral responsibility to give them equal access to its teaching and learning very seriously.  It has been making substantial investment within the Moodle community to address the current deficits in accessibility of the software.  This paper reflects on this process and more general issues of accessibility in community based and open source software developments.

6/8 Papers (20 min each + 5 minutes questions)

• Innovation and Research accessibility issues on eLearning: a user modelling approach [Jesús G. Boticario]
• Accessibility requirements in .LRN [Olga C. Santos]
• More talks to be selected

Discussion among the participants regarding the topics presented previously and others that arise

Conclusions from the session to feed back .LRN/OpenACS community

Proposals:

You can send the proposals for papers to the Workshop call or to the contact below.

Contact:

For questions contact Olga C. Santos
R&D Technical Manager
aDeNu Research Group (UNED)     

 
Last modified: 2017-06-29 04:11:17.78443+02

2007 Project Ideas for Google Summer of Code

Created by Matthew Burke, last modified by Benjamin Brink 29 Jun 2017, at 04:09 AM

Listing of potential projects for the Google Summer of Code 2007.

.LRN is serving as the mentoring organization for this project, but because .LRN is almost exclusively built on top of the OpenACS Web Application Toolkit  project ideas that benefit one or both are welcome.

• Projects that improve or add to the web accessibility of both .LRN and OpenACS for the disabled (please contact the .LRN leadership team with questions and requests for details about the related .LRN Zen Project: honchos [at] dotlrn [dot] org)
• Projects that improve or add to the translation infrastructure (e.g. translation server and translation package) to  better support non-English speaking users (OpenACS/.LRN has an advanced translation infrastructure that has a web UI for translation, but it could use some help). Examples:
  • Projects focused on improving version management and term alignment across languages
  • Projects focused on adding translation support tools
  • Projects focused on helping teams collaborate on specific localizations online (improved version control etc.)
• Projects that add or improve E-Learning standards compliance in .LRN (e.g. IMS LD, IMS QTI 2.0/2.1, SCORM 2004 3rd Revision)
• Projects that focus on application integration (e.g. adding comments package support across all applications, adding ratings package support across all applications)
• Projects that focus on object orientation support and agile software development
• Projects that extend the OpenACS workflow package (help make them more standards compliant, support state dependent attributes, etc.)
• Projects focused on game-based learning in online learning environments
• Projects focused on adding adaptive learning support to online learning environments
• Projects focused on improving the packaging and distribution of the software (e.g. apt-get/yum/etc.)

Suggestions:

1. When dealing with multiple translations a change in the source language creates a logistical problem b/c all target languages should be reviewed. The suggested work would focus on creating a notification system that informs translation teams when a term has been changed, offers a way to include a little note for the teams, and offers translators a quick way to reconcile the changes.
2. The large number of applications in .LRN/OpenACS results in multiple occurrences of the same term in different the various translation catalogs (e.g. the word "delete" is an example that is used often, appears in multiple applications, and should only have to be translated once). The suggested work would focus on a community glossary that integrates with the translation UI. For each object being translated glossary terms are highlighted in the base language and any relevant translations of the glossary items are presented along side the object being created/edited. The work should help build consistent use of terms in the source language's content and in any translations. A glossary can include phrases and abbreviations and warn translators when the terms are used in multiple packages.
3. Add functionality that analyzes translated message keys for words not in various spelling dictionaries as they might be candidates for correction.
4. On websites of sufficient size, a consistent look and feel for users is important, while for site publishers and administrators, de-coupling the UI from programming allows for easier maintenance. The OpenACS templating system provides a mechanisms that allows programmers to make changes to widgets that are then available across all applications. This makes it possible for a student to contribute in a way that has lasting effect across all applications. An example that could be worked on in the context of the GSoC: addition of some accessible AJAX functionality to the forum-building or list-building procedures.
5. IDE improvements:
   1. Eclipse improvements (contact Malte Sussdorff for ideas)
   2. Emacs improvements
   3. TextMate bundle support
   4. $your_favorite_ide support
6. Improve the functionality of nsgd. Nsgd is a module for aolserver that allows for dynamic graphics generation via Tcl scripting of the gd library. Nsgd has recently undergone a major revision but there are still a few important functions to be added including the following: allowing graphics to be shared between threads, integration with the charting module, and finish the implementation of a sparkline library.  In addition to benefiting .LRN and OpenACS, this work would be quite useful for any and all projects using AOLserver.
7. Reference management module. Needed functionality includes import/export of BibTeX data, generation of works cited lists in APA, MLS and other formats, and improved multi-user annotations.
8. Provide an automatic classification system for the reference management module.  Assign bookmarks to categories automatically using, perhaps, libbow.
9. Integrate AOLserver with AOL's Instant Messaging Library.  Not sure about the licensing.  Now that AOL has _finally_ released a library and granted permission for making AIMbots, create integration code so that AOLserver can send information via AIM as well as HTTP.
10. Create a module for compiling, linting, and other basic checks of uploaded student code.  In particular, support Eclipse and BlueJ.  Allow students in a .LRN class to upload source code which is compiled and tested.  Reports sent to student and teacher.
11. Explore using the IMS Learning Design specification support in .LRN to model adaptive learning experiences.
12. Explore integration of game-based learning tools with .LRN (e.g. passing results from an adaptive game back to .LRN)

2006 November 2nd (General Web Applications Focus - OpenACS)

Created by Dave Bauer, last modified by Benjamin Brink 29 Jun 2017, at 04:07 AM

Keynotes and Schedule

Here is a list of topics people have expressed an interest in discussing at the LRN/OpenACS Fall Conference 2006

• Future of OpenACS platform
  • XOTcl's role in OpenACS
  • More focused platform/products to give you a head start (dotLRN, dotCommunity)
  • What is the potential of a kernel rewrite?
  • Timeline for a lickable openacs.org
  • Building an easy and complete installer
  • Supporting theming (better CSS/HTML local customizations)
  • Supporting accessibility requirements
  • Package Inheritance, better re-usability of code without forking
• OpenACS Best Practices
  • Automated Testing: How and Why (Dave Bauer)
  • Package Design

For those interested in participating in the 'what is the potential of a kernel rewrite?' discussion, here is a set of questions to think about.  They are aimed at establishing the general point of view of those taking part in the discussion; ie. you don't need to answer them now or post a long article justifying your perspective.  Simply knowing your answers and being able to compare them directly to other people in the discussion will help us get something useful out of it.  You may also find it useful to consider these questions first from an optimistic perspective and separately with your own assessment of what is realistic (as people will have wildly different opinions of what is practical which may in turn hide the fact that people agree in principle).

First some questions to establish the context of your thinking:

What state is OpenACS in now?

• Almost there or needs a lot of work?
• In need of radical, non-backwards compatible improvements or more conservative, backwards comparable improvements?
• In need of cross package architectural improvements or localized incremental improvements?
• In need of documentation/idealogical changes or practical code changes?

Would you like to see all effort focused on incremental improvement? radical change? both in parallel (if so how should it be organized)?

What is OpenACS?

• A toolkit (ie. complete components which can be brought together with glue code to make a complete system)?
• A template (ie. a system with blanks that need to be filled in to complete it)?
• A complete system (ie. only required configuration to get a finished system)?
• A content management system (ie. mainly for publishing)?
• A community / social networking system (ie. focused on delivering functionality to groups of non-admin users and enhancing the relationships between them)?
• A collection of highly interactive apps (ie. a forum, survey tool, etc and some navigation to get between them)?

If your not sure what it is now, what do you think it should be?

Should OpenACS require local customization or be entirely configurable?

Second some high level questions to establish your priorities:

What are your aims for an improved OpenACS?

• Easier exchange of code between developers? (ie consistent context)
• More people using OpenACS in total?
• Improve QA in releases?

How should the OpenACS architecture be decided? 

• By TIPs (if so how will the work be funded)? 
• By anyone how has the resources to write the supporting code (if so how will long term consistency be achieved)?

Thirdly some low level questions to get the basics of your practical proposals:

What do you like about OpenACS now?

What are the biggest problems with OpenACS now?

What is your OpenACS wishlist?

What are your OpenACS implementation plans in practice?