Forum OpenACS Development: 4.6 release - merging new-portal and friends into OpenACS

1: 4.6 release - merging new-portal and friends into OpenACS

Posted by Janine Ohmer on 08/19/02 05:26 PM

A couple of weeks ago, Ben and Don reached agreement that new-portal
and the portlets should be part of OpenACS, not dotLRN. This was
decided in part, if not in total, because of a desire to move towards
portals-based admin pages.

Now that Ben is off on vacation it's a bit iffy whether this work can
be completed in time for 4.6 or not. I'd like to ask Don to post here
with more details on this task, both what's required to do it and the
reasoning behind it, and then hopefully we can get some discussion
going about whether this is important enough that we should try to
recruit someone to do it in Ben's absence.

2: Response to 4.6 release - merging new-portal and friends into OpenACS (response to 1)

Posted by Arjun Sanyal on 08/21/02 06:03 AM

i am the author of the new-portals package and many of the portlets, so i can make the relevant decisions while ben is on vacation.

new-portals in its current form works for dotlrn, but it's dm, apis, and other parts are not as clean as i would like for a package that
people will be building on. i'm working on a thorough refactoring that should be completed in time for inclusion into 4.6.

3: Response to 4.6 release - merging new-portal and friends into OpenACS (response to 1)

Posted by Lars Pind on 09/19/02 06:10 PM

Arjun,

Is this still the case?

/Lars

4: Response to 4.6 release - merging new-portal and friends into OpenACS (response to 1)

Posted by Arjun Sanyal on 09/19/02 11:17 PM

Unfortunately, Lars, it's not. Here's the email I sent to Janine
a week and a half ago.

--

Yon and I are working hard on rewriting new-portal and the portlets
from the ground up. Ben is _not_ working on it and so his schedule
has no bearing on it.

That said, the rewrite is taking some time since new-portal is large,
fairly complex, and it's an api that must be solid and relable for
other packages to use it. It must be well tested and upgradable.

I was optimistic that it would be on time for 4.6, but given the
tight deadline for 4.6 it's unlikely that it will be done in time.

I don't recommend releasing new-portal on the timeline set for 4.6.

5: Response to 4.6 release - merging new-portal and friends into OpenACS (response to 1)

Posted by Talli Somekh on 09/19/02 11:32 PM

Arjun, I think it's great that you guys are rewriting the package so
that it's cleaner and easier to develop with. But why not finish
what is available now and get it into the core system, or at least
do the new development in public?

I imagine the community would be happy to help develop it
some way, or at least have a chance to watch what you're doing.

talli

6: Response to 4.6 release - merging new-portal and friends into OpenACS (response to 1)

Posted by Janine Ohmer on 09/20/02 12:17 AM

Sorry, I took new-portal and the portlets off of the project status page when Arjun sent me that, but I forgot this thread was here.

7: Response to 4.6 release - merging new-portal and friends into OpenACS (response to 1)

Posted by Arjun Sanyal on 09/20/02 02:20 AM

Talli,

This is finishing the current stuff. I never said that new-portal was
completed to my statisfaction. If it were, this refactoring wouldn't
be necessary. I won't mention "Sanyal's Rule of 2" at this point.

Some context on the changes: I used the word rewrite, but really
it's a thorough refactoring. The core arch will not change much, but
everything else is in play. We don't plan on any new features in this
release. We will provide upgrade scripts and docs.

We'er open to suggestions based on the current code, but Yon and I
have decided not to release early, so there's no ambiguity as to
when we consider it done.

8: Response to 4.6 release - merging new-portal and friends into OpenACS (response to 1)

Posted by Talli Somekh on 09/20/02 04:01 AM

Arjun, I would never dream of questioning anything related to "Sanyal's Rule of Two." Anything as ancient and wise as that is axiomatic and it's mere mention make me orgas - er, makes me contemplative.

I, too, have a rule which I call "Somekh's Full of Pooh" which states that it's probably best that a bloke on a steed not take heed from the words of talli'd.

That being said, any chance you guys can at least post a road map of what and how you plan on improving the new-portals package? It would be a waste if people were to develop apps for new-portal while your changing APIs and such, particularly as it will be an important package for 4.7 and >.

If such a document were released so that people had a sense of what would be the improvements without impeding your hacking flow.

talli

9: Response to 4.6 release - merging new-portal and friends into OpenACS (response to 1)

Posted by Jon Griffin on 09/20/02 04:29 AM

This is another case of "lets get the damn core finished".

There really is no need to release packages with the kernel, (I realize that Don wants that for this release but it is counter to the whole point of packages in the first place).

As soon as it is ready it should be released and hopefully won't depend on a head version of OpenACS.

10: Response to 4.6 release - merging new-portal and friends into OpenACS (response to 1)

Posted by Arjun Sanyal on 09/20/02 05:24 AM

Ancient rules aside, the current refactoring won't change the semantics of the small public interface to portal. For existing portlets, the syntax of the calls to portal will change somewhat, but they will be more consistent and clearer. For future portlets, I don't see lots of disruptive API changes in the near term.

11: Response to 4.6 release - merging new-portal and friends into OpenACS (response to 1)

Posted by Lars Pind on 09/20/02 05:34 PM

I asked Yon what those changes are. Here's what he said:

datamodel-wise, i have removed some tables and renamed several of them. clean up columns: that means standardize on names, remove extra columns, add necessary columns, etc.

pl/sql api is being standardized. some parts of the data model were acs_objects and other were not, for no particular reason. this is being standardized (to NOT acs_objects).

tcl api is being cleaned up (very thoroughly). it is being split up into separate namespaces (and files). everything was in one huge file as you can see for yourself.

we are splitting into separate files and namespaces. one file for portal:: another for portal::datasource::, portal::layout::, etc.

parameters for the tcl api's are being cleaned up thoroughly as well: all functions will use named params, calls are being made more consistent. a lot of functions were taking too many arguemnts, or too few arguments. this is all being fixed.

Hope this helps clear the situation some.

/Lars

12: Response to 4.6 release - merging new-portal and friends into OpenACS (response to 1)

Posted by Ben Adida on 09/20/02 08:33 PM

Just a note to complete the picture: I asked Yon and Arjun to work together to
fully clean up new-portal. It's one of the most complex pieces of code to
emerge from the dotLRN project, and my very iterative approach to software
design left a big mess of code.

The interesting point here is that the cleanup is being done in parallel with a
documentation effort for new-portal. It's an opportunity to make sure that
everything is consistent, that code is not too redundant.

Of course, the one disadvantage is that this massive cleanup is fairly atomic,
and can't really be committed halfway. But we think it's worth doing.
Thoughts?

13: Response to 4.6 release - merging new-portal and friends into OpenACS (response to 1)

Posted by Talli Somekh on 09/21/02 10:10 PM

Ben, I think that's all cool. It would be nice if you could expand a bit on what Yon told Lars, though, and perhaps give a bit of a timeline for the work. But I'm excited about the documentation.

talli

14: Response to 4.6 release - merging new-portal and friends into OpenACS (response to 1)

Posted by Ben Adida on 09/30/02 05:11 PM

Talli,

This is a code cleanup and API cleanup. That's really it. Feature wise, this will be the same thing.

Where timeline is concerned, we're looking at about 3 more weeks of work, which will also include a rewrite of the existing portlets and a guideline as to how to upgrade your existing portlets (a few hours of work at the most for anyone who's already written a portlet).