 |
 |
|
 |
||||||
Projects .LRN Project Site .LRN TAB Tab Chat 2003-01-28
We will take a look at the testplan Bart produces, discuss next week. Jeff will check in with Bart on where it stands.
We will work more on the charter doc via email. Hopefully Don will have it in shape this coming week.
Short discussion on acs-subsite, with the long term view of getting it to the point where it would replace most of the custom dotlrn equivalents. Lars is going to look into the UI a little and Jeff will look at pieces which may belong somewhere else in the toolkit.
Lars gave a short status update from Lars on i18n. No action items.
We discussed Joel Aufrecht's OpenACS 4.5 Instant Gratification Install. We agreed we would send him some constructive criticism but general think he has done a lot of work and a great job on this.
There is a forum thread for followup discussions
Jan 28 17:04:35 <lars>
I want to move a handful of my packages over to use CR
Jan 28 17:04:57 <lars>
workflow should use it for the activity log, blogger should use it, bookshelf
Jan 28 17:05:33 <lars>
bug-tracker, too
Jan 28 17:05:43 <lars>
(though all the substantial text stuff is going to sit in WF activity log)
Jan 28 17:05:44 <donb>
Yes indeed
Jan 28 17:05:53 <lars>
I could use some guidance on the right way to do that
Jan 28 17:06:19 <donb>
This would be a good opportunity to get a little API enhancement written ...
Jan 28 17:06:26 <jeff>
lars: it's too late, we have decided you are part of the secret evil plot to replace CR with "CR but in acs_objects and then create acs_objects_lite which looks exactly like acs_objects does now" :)
Jan 28 17:06:45 <donb>
can you e-mail me a reminder and in the next day or two I'll ship you off some pointers to existing code and maybe some ideas for new API?
Jan 28 17:06:59 <donb>
ha!
Jan 28 17:07:24 <donb>
I wish Dan were here now because he knows the CR and CMS better than I do
Jan 28 17:07:41 <lars>
:)
Jan 28 17:07:49 <donb>
though he's not been in it recently (he did the port to PG - grok that for a moment, it was a horrendously large task)
Jan 28 17:09:37 <jeff>
On the community-member service contract side: the issue I see is if you have a contract per package and 9000 packages mounted that a lot of db queries. If you switch that to content types then it can still be a lot of queries.
Jan 28 17:10:18 <-- danw (~wickstrom@208.184.248.88) has joined #dotlrn>
Jan 28 17:11:36 <donb>
Lars - a better Tcl API to the CR would make it easier to support both PG and Oracle in packages like (harumph!) bug tracker
Jan 28 17:12:25 <donb>
Dan - Lars has decided he wants to become a good CR citizen
Jan 28 17:12:35 <danw>
glad to hear it.
Jan 28 17:12:54 <danw>
I wish we could get everyone on board for being good CR citizens.
Jan 28 17:13:19 <lars>
Good documentation, or a good example application, is all it takes, I think.
Jan 28 17:13:30 <donb>
Do folks think the notion of optional non-versionable cr-items would help? i.e. one object per item-revision if you don't need versioning?
Jan 28 17:13:35 <lars>
What's the canonical example CR application today?
Jan 28 17:13:41 <lars>
Not file-storage, neh?
Jan 28 17:13:42 <donb>
CMS :(
Jan 28 17:13:51 <donb>
file-storage has issues
Jan 28 17:13:51 <danw>
news uses it too.
Jan 28 17:14:02 <lars>
Last time I checked, CMS was broken
Jan 28 17:14:06 <lars>
(page errors)
Jan 28 17:14:21 <donb>
really? damn
Jan 28 17:14:25 <danw>
I'll have to take a look.
Jan 28 17:14:29 <donb>
needs looking into ... it was working in 4.5
Jan 28 17:14:48 <danw>
it worked early on in 4.6 too.
Jan 28 17:15:11 <lars>
I haven't tried playing with CMS in a while, though.
Jan 28 17:15:30 <lars>
It could well be working now, I just don't have it in my schedule to try out CMS every week ;)
Jan 28 17:14:27 <jeff>
Oh, one bug in the CR datamodel I have been thinking about: storage_area_key is in cr_items rather than cr_revisions which means you can't have one revision in the DB and then the next in the filesystem.
Jan 28 17:14:49 <donb>
That's one to discuss with Dan ...
Jan 28 17:15:26 <danw>
I thought about that when I did it, but I wasn't sure that I wanted to make that restriction.
Jan 28 17:16:14 <danw>
lars: you could do it on Monday, and then you could really claim that monday's suck.
Jan 28 17:16:44 <danw>
Jeff: why do you want to move storage_key to cr_items?
Jan 28 17:16:59 <jeff>
it is in cr_items now, should be cr_revisions
Jan 28 17:17:10 <danw>
Why?
Jan 28 17:17:40 <jeff>
because as it stands you cannot change where you store an item once it is created.
Jan 28 17:18:08 <danw>
Applications could if they wanted to.
Jan 28 17:18:43 <donb>
But then you couldn't retrieve the old revision, right? I guess my question is "how often to people really need to do this"?
Jan 28 17:18:47 <jeff>
say you want small items in the db but large ones as files on disc. one revision is below the threshold and goes in db but then a large one is loaded. It has to go into the db since cr_items says so.
Jan 28 17:19:23 <donb>
hmmm...that might be a plausible scenario
Jan 28 17:21:32 <jeff>
you also can't have new revisions go to a different disk if a partition is filling up. It just seems like it is an attribute of a revision not an item anyway.
Jan 28 17:22:18 <donb>
Ever notice how our TAB meetings are defacto OpenACS design forums?
Jan 28 17:22:26 <jeff>
Oh one other is if you decide to quit storing things in the DB you have to pull all the existing items out and update the cr_items table rather than just change the "where do things go now parameter"
Jan 28 17:22:32 <danw>
Okay, sorry I was out of sync, now I see what you're saying.
Jan 28 17:22:53 <jeff>
anyway, I just wanted to mention it since it's been on my mind.
Jan 28 17:22:58 <danw>
I was thinking that it already was part of cr_revisions. It's been a while since I looked at it.
Jan 28 17:23:06 <donb>
Dan, tell Jeff "you get to write the upgrade SQL scripts" :)
Jan 28 17:23:20 <jeff>
cool. should not be too hard :)
Jan 28 17:23:25 <danw>
donb: good point.
Jan 28 17:23:45 <lars>
Okay, who has the agenda?
Jan 28 17:23:53 <donb>
Actually .. regarding agenda I made my point to underscore why we need to get the OpenACS project more openly and obviously organized
Jan 28 17:24:19 <donb>
while I hate the idea of more IRC meetings the fact is this kind of discussion should be held in a somewhat wider audience
Jan 28 17:26:27 <donb>
sidebar: are the chats going up with comments enabled? Do we want people to be able to make comments on our work items or tech decisions?
Jan 28 17:27:05 <lars>
Let's have people comment on openacs.org bboards, no?
Jan 28 17:27:33 <jeff>
I agree with lars. gc is a black hole from which no real dialogue emerges.
Jan 28 17:27:38 <donb>
Fine w/me. This probably means Jeff posts to the dotLRN forum when he uploads the summary and invites people to comment by replying to the thread
Jan 28 17:27:50 <donb>
Jeff can post the same cut-and-paste message every week :)
Jan 28 17:27:51 <jeff>
I shall do so.
Jan 28 17:28:16 <donb>
Great ...
Jan 28 17:28:25 <jeff>
I will also link to the message at the top of the chat log (if davb has fixed the etp edit bug :) )
Jan 28 17:24:41 <donb>
Anyway ... item one (an object, not a cr_item) testing status ...
Jan 28 17:25:35 <jeff>
oh, I did post last weeks chat as well (speaking of seceret meetings and all).
Jan 28 17:25:52 <donb>
Sounds like Bart's just starting to get organized and we won't see real progress 'til next week.
Jan 28 17:28:47 <donb>
I don't think there's need for discussion, right? If things don't appear to be in motion next week then we'll have something to discuss ...
Jan 28 17:28:46 <jeff>
Has anyone ever seen the OF test plan?
Jan 28 17:28:58 <donb>
Was there one? That would be news to me
Jan 28 17:29:35 <donb>
In fact Sloan did all the serious testing
Jan 28 17:30:02 <jeff>
did they write a test plan?
Jan 28 17:30:11 <jeff>
or just test ad hoc
Jan 28 17:30:20 <donb>
No, I asked Andrew Grummet and he said it was pretty much ad hoc.
Jan 28 17:30:28 <donb>
They were under terrible time pressure
Jan 28 17:31:02 <jeff>
ok. Do we think we should be testing fully for all the input validation and quoting on output and such?
Jan 28 17:32:11 <donb>
At this point I'm willing to sit back and watch what Bart puts together for a test plan. I don't have time personally to be proactive. If anyone else wants to be proactive, though, be my guest
Jan 28 17:33:53 <donb>
OK agenda item for next week ... if Bart's test plan is done, let's discuss it briefly
Jan 28 17:33:59 <donb>
sound good?
Jan 28 17:34:14 <lars>
Yes.
Jan 28 17:35:02 <jeff>
yeah. I will probably be in touch with him to coordinate the baseline for openacs.
Jan 28 17:34:39 <donb>
OK ... TAB document etc should we discuss this next?
Jan 28 17:35:04 <lars>
Sure, where is it?
Jan 28 17:35:35 <donb>
I couldn't get SloanSpace to respond earlier so didn't put it up. But I'll describe the scope very briefly and you guys can whack at it or e-mail about it later ...
Jan 28 17:36:29 <donb>
All I did was briefly say 1. what TAB is 2. TAB encourages people to bring tech issues to us 2. How TAB makes decisions (consensus, simple majority backup) 4. How we communicate via our websites
Jan 28 17:37:00 <donb>
All the other stuff I like from Jakarta about roles of community members etc ... that really belongs in an OpenACS document
Jan 28 17:37:33 <donb>
Anyway ... if there are more points than the 4 I mention that should be included, fire away and I'll add something before posting the doc (later today, I should think)
Jan 28 17:37:44 <jeff>
I think thats about all we need. Might want to mention how we fit in with uab and eab (I guess maybe that makes more sense once we know how we fit in).
Jan 28 17:38:19 <jeff>
course that could just be a pointer to the main governance page
Jan 28 17:38:28 <donb>
There is the old governance doc on the dotLRN project page already ... maybe I can reference that? Or more correctly there should be a top-down link from the governance doc to the TAB doc
Jan 28 17:40:01 <donb>
You don't see it because I was getting a timeout this AM when I went to upload it (I finished it yesterday but ran into a friend I hadn't seen for six weeks and ended up talking to her for a couple of hours so didn't get it posted last night)
Jan 28 17:40:31 <donb>
I'll put it up and we can talk in e-mail ... I'm not sure document editing and IRC are a happy marriage ...
Jan 28 17:40:37 <danw>
Okay, I misunderstood. I thought you said that you had already uploaded it.
Jan 28 17:40:49 <donb>
tried to ... I'm a failure :(
Jan 28 17:41:36 <donb>
acs-subsite improvements ... this is a legit TAB issue because we may want to migrate some functionality from dotLRN to acs-subsite
Jan 28 17:42:04 <lars>
Yes. What's your thinking?
Jan 28 17:42:30 <donb>
The UI would remain duplicate but under the hood some of the dotLRN Tcl API for dealing with groups and rel segments should be poached and only appear once, i think.
Jan 28 17:43:14 <lars>
Yes.
Jan 28 17:43:23 <danw>
What's the reason for keeping a duplicate UI?
Jan 28 17:43:59 <lars>
Eventually we should be able to move dotlrn over to use acs-subsite, once acs-subsite has everything dotlrn needs, but I think that's a long-term perspective
Jan 28 17:44:16 <donb>
Because in dotLRN general user admin UI is intertwined with stuff that's dotLRN specific and mentions concepts like "term" etc
Jan 28 17:44:22 <donb>
(in answer to Dan)
Jan 28 17:44:24 <donb>
Lars: yes
Jan 28 17:44:52 <donb>
Dan ... more migration is probably possible but I doubt we'll have the resource to do it and properly migrate existing sites, that would be my concern
Jan 28 17:45:54 <donb>
The key thing, though, is that we have TAB consensus on the principle of migrating stuff from the dotLRN package to acs-subsite when it makes sense, and for dotLRN to use that code rather than duplicate functionality.
Jan 28 17:46:23 <lars>
That would be my approach.
Jan 28 17:46:41 <donb>
Would it make sense for me to do a survey in the next couple of weeks and put up another doc ala the perm scalability doc?
Jan 28 17:46:49 <donb>
Or would one of you like to do so?
Jan 28 17:47:16 <donb>
Lars ... you've already put quite a bit of thought on the usability side ...
Jan 28 17:47:43 <lars>
I want to put together a UI design of sorts
Jan 28 17:47:46 <lars>
mock-up, perhaps
Jan 28 17:47:58 <lars>
figure out what I think acs-subsite should look like, what it should do
Jan 28 17:47:33 <jeff>
donb: how likely is it that existing sites move to dotlrn 1.1 anyway. I doubt they will want to suffer the pain of the i18n upgrade.
Jan 28 17:48:03 <donb>
OK ... (jeff, let's table your Q for a moment)
Jan 28 17:48:11 <donb>
That would be great, Lars ...
Jan 28 17:48:42 <donb>
How about I take a look at the under the hood stuff (I just did a quick check and actually dotLRN's pretty much built on top of existing OACS API)
Jan 28 17:48:50 <donb>
And you put together a UI mock-up
Jan 28 17:48:59 <lars>
That sounds perfect to me.
Jan 28 17:49:05 <donb>
That way you get stuck with most of the work ...
Jan 28 17:49:11 <donb>
so it sounds good to me, too
Jan 28 17:49:44 <donb>
OK so our TAB summary should state the principle I mentioned above (we want to migrate such functionality as practical)
Jan 28 17:49:55 <lars>
I get stuck with the work where I feel I have something to contribute :)
Jan 28 17:50:13 <donb>
and that Don will survey code and datamodel level issues and Lars will work on a subsite UI design.
Jan 28 17:50:33 <donb>
I'll try to complete my survey in the next two weeks, our summary can say that too
Jan 28 17:50:52 <lars>
I'll try to complete my UI design in the next two years or so :)
Jan 28 17:51:07 <donb>
Big Q is ... how much can be done by 4.7 (if it's not going to take two years to complete)?
Jan 28 17:51:09 <jeff>
if we are thinking about acs-subsite maybe we should also think about what could be pulled out as well since it is almost like acs-tcl-lite with some things in there that really should not be.
Jan 28 17:51:20 <donb>
yes yes yes!
Jan 28 17:51:33 <donb>
user registration is another issue ...
Jan 28 17:51:48 <lars>
Yeah, Jeff, you volunteer for that? :)
Jan 28 17:51:55 <donb>
(my thoughts too)
Jan 28 17:51:56 <lars>
You want user registration our of acs-subsite?
Jan 28 17:52:18 <donb>
Well ... does it really belong there? Users have to be registered at the top level, the way things are set up today
Jan 28 17:52:45 <jeff>
lars: I will make a list of possible things to move.
Jan 28 17:52:47 <donb>
You have to be registered as a site user then you get joined as a member to a subsite (except that never happens because subsite's so obtuse)
Jan 28 17:53:01 <donb>
that would be great, Jeff
Jan 28 17:53:11 <lars>
So you'd have a separate acs-register package, mounted at /register?
Jan 28 17:53:47 <donb>
Just a notion ... what do you think?
Jan 28 17:54:20 <jeff>
lars: it's definitely been my experience that registration is one thing that almost always gets extensively changed on real sites
Jan 28 17:54:27 <lars>
I'm not particularly against it, I just don't really have much of a problem with having it there
Jan 28 17:54:59 <lars>
now that's a different issue ... login as an include-able template
Jan 28 17:55:04 <donb>
I think it's more conceptual ... i don't really care where its stuck so much ... currently subsite doesn't actually support the concept of one joining a subsite (which dotLRN has)
Jan 28 17:55:15 <lars>
and making it easy to give the forgotten password etc. pages the look you want
Jan 28 17:55:18 <jeff>
seperating it out would mean that sites could more easily pull in new code to acs-subsite w/o having to necessarily deal with merging registration.
Jan 28 17:55:31 <donb>
Jeff: yes
Jan 28 17:55:53 <donb>
Might also make efforts to integrate with things like LDAP authorization easier to logically organize
Jan 28 17:56:24 <lars>
okay, let's see some use cases for this as part of the research that we're each going to do on this.
Jan 28 17:56:24 <donb>
wandering around acs-subsite to see where OpenACS integrates with LDAP, for instance, isn't necessarily the most intuitive thing in the world for a newcomer
Jan 28 17:56:59 <lars>
Ok. As I said, I'm not against pulling it out at all.
Jan 28 17:57:02 <donb>
Excellent. I'm thrilled that we're finally at a point where we can actually talk about subsites (i.e. that the panic level over other flaws has slowly dropped)
Jan 28 17:57:19 <lars>
Maybe /register, /pvt, and /user belong in the same package, then...
Jan 28 17:57:33 <donb>
Perhaps ...
Jan 28 17:57:48 <donb>
One argument against breaking it out is that user admin wants to be subsite-coped
Jan 28 17:57:51 <donb>
scoped
Jan 28 17:58:01 <donb>
there's nothing special about the top level ...
Jan 28 17:58:56 <donb>
dotLRN hasn't quite bridged things entirely ... making a user is transparent (they're made a registered user and joined to dotLRN) but user-initiated joining is a bit funky still
Jan 28 17:59:21 <donb>
OK ... we have work to do offline on subsite planning, very good
Jan 28 17:59:22 <jeff>
it is iffy to force non EN sites to have urls that say permissions register and shared in them.
Jan 28 17:59:44 <donb>
They already do :)
Jan 28 17:59:59 <donb>
Are URLs really a big issue?
Jan 28 18:00:04 <lars>
Jeff, I think it's a bit too luxurious to worry about that at this point ... i18n is still only halfway finished...
Jan 28 18:00:52 <jeff>
I don't know. Ultimately it's a concern. down the road I imagine we will actually map full urls to pages.
Jan 28 18:01:05 <donb>
Big CR item not addressed by current heidelberg funded work: content language stuff, it's all Oracle specific
Jan 28 18:01:26 <lars>
ugh
Jan 28 18:09:25 <donb>
I looked at acs-lang and locale choice for users seems to be there ... but how about non-registered visitors?
Jan 28 18:09:53 <lars>
non-registered users are cookie, iirc.
Jan 28 18:10:14 <donb>
OK ... are reg users cookied once they choose? I'm thinking scalablity ...
Jan 28 18:11:02 <lars>
No, we didn't do that. That'd be item 1 on the list (scalability) :)
Jan 28 18:11:20 <lars>
scalability is pretty poor right now, we hit the DB on every single request. but it's pretty simple to fix.
Jan 28 18:12:15 <donb>
OK just doing that would probably help a lot ...
Jan 28 18:12:37 <lars>
Yes, that's a must
Jan 28 18:13:19 <donb>
will we have both a pretty name and message key stored or just message key? I'm thinking that it might be reasonable to allow those doing custom one-language packages to ignore multilingual cruft
Jan 28 18:13:39 <lars>
Both.
Jan 28 18:13:41 <lars>
The way we've done this so far is actually to store the whole "#package_key.Message_Key#" string in the database
Jan 28 18:13:45 <donb>
Good
Jan 28 18:14:14 <lars>
and then run it through some proc before displaying it
Jan 28 18:14:19 <lars>
that way you can do either
Jan 28 18:15:02 <lars>
It's not terribly elegant, but it works
Jan 28 18:15:11 <donb>
I wish SQL was smarter about types and objects in a portable way ... I guess you'll just have to document the right way to do pretty names for well-behaved acs objects?
Jan 28 18:15:14 <lars>
so long as you don't write stuff in your prettynames that resembles a message key
Jan 28 18:15:33 <lars>
Yes
Jan 28 18:15:50 <donb>
And provide some UI and maybe some form snippets people can use?
Jan 28 18:15:54 <donb>
I meant api
Jan 28 18:16:28 <lars>
Yes. I'm actually planning on buildling a form builder widget for these kinds of strings which would be intelligent about locales and stuff somehow ...
Jan 28 18:16:43 <donb>
ahh, cool ... widget and datatype, no? :)
Jan 28 18:17:00 <donb>
Yeah ... that's a great idea, do it in the form builder
Jan 28 18:17:17 <lars>
I wonder if we'd need the datatype in this case, but sure :)
Jan 28 18:17:34 <lars>
Alright, what's on the agenda then?
Jan 28 18:17:35 <donb>
You can do validation if necessary ...
Jan 28 18:17:59 <donb>
That was pretty much it unless we want to talk more about Joel's doc
Jan 28 18:18:14 <donb>
I can't comment on Dirk's stuff until I see it...
Jan 28 18:18:28 <lars>
Has he posted on the forums?
Jan 28 18:18:42 <lars>
I think it would be really good if you could cheer him for writing it, then offer your constructive suggestions
Jan 28 18:19:00 <donb>
Good point, lars ...
Jan 28 18:19:23 <donb>
He does cover some nice stuff like "how to make a new package"
Jan 28 18:19:46 <lars>
Yes, and we definitely need more instant gratification in OpenACS ...
Jan 28 18:19:48 <donb>
In essence chunks of the doc should be ripped out and incorporated rather than have it be maintained as a whole, I think
Jan 28 18:20:33 <donb>
The "how to lasth together a production server" stuff should be an integrated doc as it is now of course ...
Jan 28 18:20:07 <donb>
it's hard to get instant gratification when permission checking's so slow ...
Jan 28 18:20:28 <lars>
:)
Jan 28 18:20:38 <lars>
but you're fixing that now, that's good.
Jan 28 18:21:03 <donb>
Well, hopefully in the next month unless someone like Dan has time to whack at it more quickly, there's lots of grunge work involved
Jan 28 18:22:14 <donb>
Why did aD make the security context object be 0 when unregistered users are 0? I'm going to need to upgrade datamodels in place to reflect the fact that object 0 must be user_id 0 which must be part of "the world" group of all registered/unregistered users
Jan 28 18:22:32 <donb>
messy little things like that need to be worked out
Jan 28 18:22:50 <danw>
Yes but there is not person with object_id 0.
Jan 28 18:22:59 <danw>
It's kind of confusing though.
Jan 28 18:23:10 <donb>
Oh jeff quick experiment to try with the cc_user view if you have time - get rid of the call to acs_magic_object('registered_users') and replace it with "-2" and see if Oracle optimizes better ...
Jan 28 18:23:39 <donb>
Dan - that's my point, I'll need to create a party with object_id 0 and move the security context object to -4 or whatever
Jan 28 18:24:30 <danw>
That will probably break stuff.
Jan 28 18:24:34 <lars>
Alright, thanks for your time, guys :)
Jan 28 18:24:40 <jeff>
One thing I don't understand is security context root is -3 and default context is 0. so cms things root at 0 for context and everything else roots at -3
Jan 28 18:25:01 <donb>
Dan ... I looked, it shouldn't, I've tracked it down ... there aren't that many places to change.
Jan 28 18:25:11 <donb>
that's backwards ... default is -3 and security context is 0
Jan 28 18:25:21 <jeff>
yeah sorry.
Jan 28 18:25:20 <donb>
hardcoded 0 in the triggers, too :)
Jan 28 18:25:37 <donb>
I think that was a mistake in the CMS integration with ACS 4
Jan 28 18:26:09 <donb>
Dan would you have time to hack one small piece of the puzzle in acs_permissions for PG?
Jan 28 18:26:29 <danw>
Could you send me an email on what you want?
Jan 28 18:26:39 <danw>
I need to run now. My time has run out.
Jan 28 18:26:40 <donb>
Sure ... shouldn't take long
Jan 28 18:26:48 <donb>
OK I want to get out of here, too.
Jan 28 18:26:50 <donb>
We done?
Jan 28 18:26:55 <donb>
yes, thanks :)
