Forum OpenACS Development: Calendar is Available for Porting

Collapse
Posted by Dan Wickstrom on
Openforce's client has pulled out of building a new calendar module,
so we need somebody to port the existing one.

If anybody is interested in doing a straight port of the calendar
module let me know.

Collapse
Posted by Rafael Calvo on
I would be interested. Is there a timeline?
Any idea how much time it would require for a newbie?

cheers

Rafa

Collapse
Posted by Jon Griffin on
If you are talking about the 4.x version that wasn't released, it will be very difficult for a newbie. The 3.x version is simpler but not trivial (also, not very powerful).
Collapse
Posted by Dan Wickstrom on
The schedule is posted here.

The 4.x version looks like it would be pretty straight forward. The calendar package is a small package with about 20-25 functions, a couple of tables, and about 50-60 queries in the .tcl files. Most of the queries seem to be simple with very few, if any, outer joins and connect-by statements to port. There are quite a few plsql function calls, but they're pretty easy once you've done a few of them.

It looks like a good package for a newbie to port. As long as the person who does it has some free time available to work on it and they're commited to finishing it, then I don't see any problem with a newbie porting the calendar module. If you get stuck, there are plenty of people here who are glad to help out.

Collapse
Posted by Jon Griffin on
The reason 4.x was not finished was major scalability problems. It would take 4 hours to return a page, sometimes all day.

That may have been fixed with the permission_p fix that has been made, but I am not sure. I just remember discussing data models and etc when the 4.x version was planned.

Also, you need several other packages ported to have it work, most notably acs-calendar, acs-event and (maybe) acs-reference.

Collapse
Posted by Rafael Calvo on
None of the three packages Jon mentions are listed in the timetable. Am I missing something?
I am a lecturer in Univ. Sydney and I was thinking the porting job for a couple of my students (software engineering) doing theses work. I myself will also be helping.
I looked in aD's site yestarday but couldn't find the last version of calendar.
The documentation seems outdated. At least is not the same calendar module we have in openacs 3.2.5.
I emailed Scott Meeks, but he is not at aD any more.
Could someone map me the specific process for porting calendar?
Collapse
Posted by Jon Griffin on
Gary Jin wrote calendar, Scott Meeks wrote acs-event, Ron Henderson wrote acs-calendar. Of those only Ron is still at AD.

I was in on all the design as I was originally porting events and we split calendar/events common functionallity into acs-event.

If I recall acs-event was complete, I quit AD before finishing events and Sarah Barwig took over. I can almost guarantee you that it was never finished as TCL went the way of Java. I don't think I have any of the old code and don't have an account on the AD LA office box anymore. If you guys can't find it I will try to get a hold of someone in the Pasadena office and see if it is still around.

Collapse
Posted by Jon Griffin on
Thinking about it, I think that the cvs tree at AD should have it. I haven't used the AD CVS for a few months but assume it is still there.
Collapse
Posted by Dave Hill on
That sounds great, Jon. I was under the impression there wasn't an
acs-events. Perhaps given it's rather poor performance, there still
no acs-events. But at least there's a start.

talli

Collapse
Posted by Dan Wickstrom on
Ok, I've done a little digging, and it appears that the only unported packages that the calendar package depends on are acs_events and acs_object_util.  I can't find any references in the code to the other packages that Jon mentioned.

For some reason, acs_events didn't make it into our cvs archive, and it doesn't appear on the status list.  I did a checkout of acs_event from cvs.arsdigita.com, and I'll add it to our cvs archive when I get a chance.

The acs_object_util package is part of the site-wide search package which is yet unclaimed.  If we're going to port the calendar module, we need people to also port site-wide search and acs_events modules.

Even if the calendar module doesn't scale well, I still think that we should port it.  Comments in the code indicate that the scaling problem is related to permissions checking, which is something that can probably be fixed with some redesign of the permission system.  This is something that Ben is already investigating.

Collapse
Posted by Jon Griffin on
The permission problem should already be fixed enough to test this package.

I thought for sure that some of the date widgets from acs-datetime were in there... oh well.

Collapse
Posted by Dan Wickstrom on
I missed the acs_datetime dependency.  That's another package that would also need to be ported...

It looks like acs_datetime does not have a data model to port, and as far as I can tell there is only one db query in the whole package, so it shouldn't be a problem.

Collapse
Posted by Rafael Calvo on
It would be usefull if we could have a Gantt of the porting process so all the dependencies are made explicit. Can any of the "veterans" explicit something like: (200hs)
taskJuneJulyAugust
acs_events (200hs)(50hs)
acs_object_util (100hs)
calendar (100hs) (200hs)

Note that the numbers are just out of my imagination, I need someone with more experience to "budget" the effort required
cheers
Collapse
Posted by Dan Wickstrom on
I don't have time to do a good estimate now, but for each package you could get a good idea yourself by just counting the number of pl/sql procs and .tcl queries and multiplying by an estimate of how long you think it would take you to port each one on average.  For example, if you had 20 pl/sql procs and you thought that it would take you 10 minutes on average to port one, and you had had 50 .tcl queries and you thought that it would take 5 minutes to port each one of those, then you would have a total expenditure of 20*10 + 50*5 minutes for the package.

You might also want to throw in some time for debugging and testing.  Assume, for example that you will make a porting mistake on 10% of the queries and pl/sql procs that you port, and it will take you 10 minutes on average to track them down and fix them.  Your total then might look something like (50 + 20)*.10*10 + 20*10 + 50*5.

As I'm sure that you're aware of, this is all highly subjective and dependent on your knowledge of oracle and postgresql.  If you have a good knowledge of each system's flavor of sql then your average times for porting and testing will be much faster.  Since you mentioned newbies earlier, the debug and test time and the number of mistakes made will probably be much higher than the times I mentioned here.

Collapse
Posted by Rafael Calvo on
browsing through aD's cvs I find that there is another calendar package inside ACES, and it's info file says its version 1.1.1.1 the calendar package inside /packages says its version 1.2. The weird thing is that 1.1.1.1 seems to be newer (some files have been changed 7weeks ago).
which would be the right one?
Anyone porting ACES has a comment? Anyone working with Sloan?
cheers
Collapse
Posted by carl garland on
If anyone is interested ... see post https://openacs.org/bboard/q-and-a-fetch-msg.tcl?msg_id=0001kv&topic_id=12&topic=OpenACS%204%2e0%20Design I have removed all db calls with tcl and will forward code ... let me know and I will send; noone responded to my previous post so maybe there is no interest in increasing effiency ;)
Best Regards, Carl
Collapse
Posted by Rafael Calvo on
I just wanted to make more explicit that we will be porting calendar.
Unless of course the core team says otherwise. I would appreciate if someone can confirm this (Ben?).
Collapse
Posted by Dan Wickstrom on
Ok, I'll put you down on the status list as porting calendar.  I assume that you'll also port the acs_events and the acs_object_util packages as well?
Collapse
Posted by Rafael Calvo on
We will start with the dependencies of calendar on the first week of July.

We will probably be needing help, and it could come as porting one of those dependencies...

I will let you know more once we look at the code carefully and are able to budget the effort.

Collapse
Posted by Dan Wickstrom on
Ok, I put you down for calendar, and acs_events.  If you find you need help with acs_events, let us know and we'll see if we can come up with a volunteer to help out.

Since it doesn't make sense to have acs_object_util in site-wide-search, I'm going to fold it into the core.  It only consists of five utility functions for acs_object_types, so it's not a problem.

Collapse
Posted by Dan Wickstrom on
Since we somehow missed it the first time around, I've imported acs-events into our cvs, and Rafael, I've put you down as the reponsible party for porting it.  We'll reassign it later if you find that you don't have time.