Home
The Toolkit for Online Communities
17332 Community Members, 1 member online, 2245 visitors today
Log In Register
OpenACS Home : Forums : OpenACS Development : Berlin bug bash proposal : One Message

Forum OpenACS Development: Re: Berlin bug bash proposal

Collapse
Posted by Lars Pind on
Alright, let's find another date, then.
Collapse
Posted by Tilmann Singer on
Ok. Last weekend of January is not possible from my point, so what about Feb 14-15?

Feb 7-8 would work as well but they will start broadcasting radio on the beginning of Feb here from that office space, so since that is the first weekend after the launch it might be still a little chaotic.

Martin, the office space is bootlab.org - next to Oranienburgerstrasse in Mitte. I'm sure we could find someone with a car to pick you up if that is necessary.

Collapse
Posted by Malte Sussdorff on
I'm in 14th/15th of February, but would be able to make it the weekend before as well. Can someone give me a place to crash saturday til sunday ?
Collapse
Posted by Tilmann Singer on
No vetos so far, so let's say it's fixed on Feb 14/15.

I'll post details about the place later.

Collapse
Posted by Joel Aufrecht on
Some notes for preparation:

My #1 priority for the code bash and for OpenACS 5.1 is to enhance acs-automated-testing.  So all work for that, from the preparations to the deliverables at the end of the bash, should be in the form of checkins to the package on HEAD.

new functionality:
  Pri A integration of tclwebtest into acs-automated-testing
  A: simplify tclwebtest installation
  A: better test categorization
        use category package?
        see related forum posting http://openacs.org/forums/message-view?message_id=150581 for some categories
  B: define a test as a collection of other tests, in sequence
  B: macro test recording
      B: UI to turn on macro mode
      B: basic recording: when you fill out a form while macro mode is on, the submit is caught and displayed as tclwebtest code, and then executed
      B: UI for creating aa_true tests automatically, based on the content of the page.  (For example, a form that says "the returned page must contain [ type regexp here] that spits out aa_true "test X" [string regexp blah blah]

Depending on who attends (Timo, Dirk?) we could put Category on the agenda, where the work would be:
  (from http://openacs.org/forums/message-view?message_id=155128)

# UI to manage categories. This is fully implemented in the current package (but may use custom kernel code, so we would have to refactor)
# Documented code snippet to add to any OpenACS object's UI to associate the object with categories. (This is analagous to putting an "add/view comments" blurb, as documented in General_comments in Advanced Tutorial). As far as I know, this is not done.
# Documented code snippet to display category info per object. Also analagous to comments. Also not done, AFAIK.
# By adding a flag to list-builder, automatically filter objects by category. Not implemented.

Collapse
Posted by Dirk Gomez on
I can't say anything about categories because I have neither worked on it nor
with it. From brief code inspection it seems that the module currently is an
open and warm invitation to forking: It requires a table that holds object
names and probably also uses the redirection trick Timo and I have talked
about, so if you want to use this package you need to change "categorizable"
packages.

It may be a good opportunity for the OCT to take a decision: it is an
interesting module, but currently defies two major design principle of OpenACS
4.X/5.X, namely it doesn't come with upgrade scripts and it leads to every
individual programmer fork in a different way.

On the other hand I strongly dislike the idea of enforcing a technical
solution only to make some other solution work - especially given that above
table and redirection trick doesn't seem an issue to enough people.

And we haven't come to a conclusion yet on how to work on all of this - guess
I lost some interest in battling electronically in the past weeks.

Collapse
Posted by Tilmann Singer on
The bug bash will be in a place called bootlab in berlin mitte, Ziegelstrasse 21, 10117 Berlin, near S-Bahn station Hackescher Markt.
There'll be some sofas and wlan, and most likely a beamer for spontaneous presentations.

Please mail me if you are going to attend so that I can plan ahead and can send you some more details.

Collapse
Posted by Malte Sussdorff on
I'll be there.
Collapse
Posted by Bruce Spear on
Hi Guys, I'd like to join you when it might be appropriate, as we in the .LRN User Advisory Board are trying to figure out how best we might contribute to .LRN/OpenACS design and it might be helpful for me to learn more about how you work together and even more helpful if you were to figure out when and how you might want to invite us to add our two cents of opinion.  Plus, I'm designing a research project that might well involve some of you directly, as you will gather from the preliminary outline, at: http://home.arcor.de/civici01a/programming/indexdev.htm.  So, Til, count me IN.

Bruce

Collapse
Posted by Nis Jørgensen on
I'm going.

Being an OpenACS novice, I will probably be something between a Worker Bee and a fly on the wall.

When should I aim at being there?

Collapse
Posted by Martin Bernd Schmeil on
OK, I'll definitly be there and bring my new notebook, so Timo can work on categorization (hehe).

Timo, Branco and whoever else coming from Munich: My flight back (TXL-MUC) is LH237 (Feb 15, 21:15)

Collapse
Posted by Tilmann Singer on
Some more info on the Berlin Bug Bash - the address is actually

Ziegelstrasse 20
10117 Berlin

not 21 as I posted above, sorry about that. You can use e.g. www.stadtplandienst.de for a map. I would post a direct link but I think they don't allow that. When you come from S-Bahn station Hackescher Markt you walk down Oranienburgerstrasse, then turn left into Monbijoustrasse just after the park, and then to the right again into Ziegelstrasse. The bootlab is the first door on the right side in that street.

I would suggest we don't start before 11h.

So far I have the following list of people who plan to attend - could those who are in confirmed but don't come or those who come but are not in confirmed post here or send me a mail please so that we have a better idea of how many people will come? Thanks!

Confirmed:

malte
bruce
nis
nima
lars
joel
peter
timo
bernd
paul doerwald
dirk
til

Maybe:

crb
david k.
jcdldn
cmeeks
branco

There'll be wavelan and ethernet. Does anyone _not_ bring his or her own laptop and needs a computer?

My phone is +49-175 904 5055 just in case.

Collapse
Posted by Joel Aufrecht on
More notes in preparation:

A: discuss solutions to named objects archictural problem and produce TIP for voting

details (corrections welcome, of course):
The category package reveals a flaw in the OpenACS architecture, and instead of working around it in category, which is problematic, we should address it head-on.  Using category as a use case, here is the problem:

Some use cases for categories involve showing a list of openacs objects, such as all objects in a category.  In order to display such a list, the OpenACS core API provides for acs_object__name for each object, which is actually several layers of abstraction in both SQL and TCL.  However, the performance is unacceptable and this is probably a structural problem.  We also need a URL for each item, and the OpenACS core API does not provide for this.

Category solves this problem by creating an acs_named_objects table.  This is a denormalized table containing object names.  This table is empty, however, and the details of filling it will vary by package.  Thus, anybody who installs category cannot use functions that use this table unless they also change every other package in OpenACS.

Category solves the URL problem by "using /o/OBJID to defer URL lookups. so it's ok if its a slow function lookup since it's only done one object at time when someone clicks on a link" (jcdldn).

Solution 1: Make acs_named_objects a core table; document the work required per package to populate it; do this work for the core packages.

Solution 2:  Today packages create their own implementation of acs_object__name which is called by acs_object__name. The value of this function is typically something package-specific, or something trivial like "Object #123456". Packages should have triggers on the table where the data ultimately comes from that update acs_objects.name or acs_named_objects, in lieu of true functional indexes on acs_object__name.  (guan)

References:
http://openacs.org/forums/message-view?message_id=94366
http://openacs.org/forums/message-view?message_id=85086
http://openacs.org/forums/message-view?message_id=94374

Collapse
Posted by Joel Aufrecht on
I've converted these notes into a slightly more formal Requirements document. Some questions:
  • Requirement 3, tests which are ordered lists of other tests, can (maybe) be done already simply by calling other tests from within one test. If you can't invoke a test from within another test now, should we hack that in? Would that then be enough to cover all of tammy's case for reusing setup/teardown procs etc?
  • Is the (new and improved) catalog file functionality for translations something we can use for automated tests? If we have a public test server where anybody can submit a new test, we have basically the same sync problems as on the public translation server.
  • Do we need to use the category? Is it ready?
Collapse
Posted by Joel Aufrecht on