Forum OpenACS Development: Re: new acs-rels, orgs, persons functionality (widgets etc.) to commit

9: Re: new acs-rels, orgs, persons functionality (widgets etc.) to commit (response to 1)

Posted by Don Baccus on 07/22/04 11:49 PM

Hmmm...there's a lot of other cruft in acs-subsite that builds on rels - group UI, relseg UI, and all that stuff. It would be nice to have all that kernel UI stuff out of the subsite dumping ground - "acs-kernel-ui" perhaps? But then ... why not have kernel ui in the acs-kernel package? I have to admit, though, that it doesn't particularly bother me that this stuff's in acs-subsite.

For a long time I've wished acs-tcl was restricted to utility Tcl procs not related directly to our kernel datamodel (i.e. things like ad_page_contract) with kernel Tcl API in acs-kernel...currently we have some kernel Tcl API in acs-tcl, other bits in acs-subsite, and that's just wrong.

11: acs-tcl package (response to 9)

Posted by Andrew Piskorski on 07/23/04 06:56 AM

Yes, it sure would be nice to be able to take the stock OpenACS acs-tcl package (with ad_proc, ad_page_contract, the db api, watchdog procs, etc. etc.), drop it into a plain old AOLserver with no OpenACS, and have it Just Work. Last time I did something like that, it required lots of fiddling just the parts I needed to work at all.

13: Re: acs-tcl package (response to 11)

Posted by Malte Sussdorff on 07/23/04 10:52 AM

Hi Andrew, could you do the effort again (taking out the acs-tcl package) and clean it up so that:

- All procedures that are required by acs-tcl that are independent of OpenACS but somehow made it into a different directory, are moved into acs-tcl.
- All procedures in acs-tcl that rely on code in OpenACS are moved to acs-kernel.

If I'm not mistaken this should enable us to maintain an acs-tcl package that is clean of OpenACS dependend code and can be reused everywhere else. We might even upload all these enhancements to the AOLserver CVS 😊.

I'd assume if we want to make a policy out of this, we would have to TIP this, therefore it would be nice to get some feeling if people agree to be doing this. I for myself am sold to the idea and it makes a lot of sense to me (as I was always wondering why we have acs-kernel and acs-tcl and this differentiation posted by Andrew makes utter sense and should be published in guidelines).

14: Re: acs-tcl package (response to 13)

Posted by Andrew Piskorski on 07/24/04 07:00 AM

Malte, since it's clear now that other people would like it too, yes, I'm willing to work on acs-tcl as you describe. Not right now though, and I can't give you a timeline either, as I have other things on my plate at the moment. But I'll definitely add it to my list as of now.