Forum OpenACS Q&A: Re: GPL and the use of GPLed Code in Commercial Products

Trying to get a grip on what Frank is talking about in his functionality and what core offers here is a small "translation" guide :).

- Menus: Menus are tabs in the tabbed subsite view or portal pages in portals. All systems allow the dynamic extension of the functionality. The subsite and menu view limits this to packages (at the moment), the portal system is more dynamic in this regard, though it does not support submenus as the subsite and menu system allow. Ideally subpages should be implemented in portals. Franks documentation is at http://www.project-open.org/doc/intranet-core/menus.html.

- Components: Components are basically portlets. Within Frank's system they are stored in the database. With .LRN the portlets are stored in the file system and served from there. Usually the OpenACS approach is to keep as much information stored in /lib includes, so both portlets as well as other systems (e.g. Frank's component system) could access it. Would be nice to see Frank switch to this model.

- Dynamic Views: This is something that is missing at the moment from Listbuilder and is something we are going to add to it. The ability to enable / disable certain columns in a list view is great. Where it get's interesting though is when you want to add special columns that are derived from other packages. I guess this needs some thinking on how to implement it best (I assume callbacks again, but making callbacks dynamically hook into listbuilder with dynamic extension of the SQL query, can be challanging :)).

- Categories: The OpenACS is considerably better. Don't bother :).

- Permissions are mostly the same with regards to functionality though the implementation is considerably different. Here is a quote from Franks documentation (http://www.project-open.org/doc/intranet-core/permissions.html) why he did not use ACS Permissions:
"The complexity of evaluating and storing permission permissions needs to be considerably below O(n * m) with n=number of objects and m=number of users in order to be suitable for organizations with up to 100.000 users and up to 100.000.000 business objects to be managed. (I wouldn't be practical for example to apply the OpenACS permissions system directly to a filestorage with 10.000.000 files and 10.000 users, because its denormalization triggers would build an O(n * m) denormalized index)."

- Offices / Customers. This can be represented by the contacts package of Matthew Geddert with the additional benefit that you can extend the fields dynamically. I assume it should even be possible using callbacks to add a field e.g. to a contact like billable_p if the invoicing module is installed. Obviously this needs a small change in AMS.

- Projects. Well, there is project-manager and Frank did not like the look of it whereas I do not like the datamodell / technical implementation of Frank so it is up to anyone to decide what is best. We are working on PM together with Jade and others adding dynamic types support for attributes of tasks and projects, enhancing permissions (Richard) and generally making it more friendly to use (UI Changes).

So, in total, there is much to learn from Frank's approach and it is sad that the communication did not happen consistently some time ago, as this leaves us with fundamentally different technologies that are incompatible with each other, though they can coexist. But with regards to community effort, it is either support the P/O way of doing things or support the OpenACS way.