Forum OpenACS Q&A: What should be included in OACS 4.6

As people have been start to discuss OpenACS 4.6 in a different thread, I thought a little about what I'd like to see in the OACS 4.6 release:
  • Internationalization support both for content as well as the system itself (at least charset issues should be solved and the framework for adding language packs)
  • Fixing of the known bugs in the various packages
  • If people are keen on adding more features to the packages after all bugs have been fixed, why not.
  • Not knowing how hard a port from dotLRN to OACS will be (especially with PG support for all that is ported), I'd love to see portals.
  • PG/Oracle support for all packages (so all packages should support both databases). If this is not possible due to ORACLEish specialities, try to find a workaround if this package is actully used (at the moment I can only think of webmail, and it sucks, so no need to bother IMHO 😊).
To sum it up, the main focus should be on stability and fixing of defects with thinking of DB compatability. Adding multi language support is crucial for some of us (e.g. me), therefore I'd love to see it in the release and help working on getting this done. But if it breaks a timeline (e.g. September), than better get the bugfixed release out. Release often (once clean of bugs, mostly).
Collapse
Posted by defunct defunct on
And for something completely different...

I think any new major release needs to be a balance of restrospective and quality based work, minor enhancements and so forth.. but also needs some new, creative, 'cutting edge elements.

The world's moving on, the ACS is still largely based on ideas and requirements from 1997 (Ala Mr. Greespun's book) and important and vital though that is I think we also need to be looking to the 'next thing'

I think the comunity needs to identify some area(s) not well understood or addressed at the moment to attract in new thinkers, move the kit forward, and steal an edge on the alternative.

Who know what this might be... VoiceXML perhaps, Mobile Video Streaming or perhaps location based services... answer on a postcard

In summary I'm saying a lot of efforts gone into this toolkit, much of it compensatory for AD's misdemeanours, and perhasp now we should entertain some new, more bleeding edge, elements.

Simon

Collapse
Posted by Malte Sussdorff on
Oh, I forgot. We should have scipts for upgrading from the 4.5 release which could handle the upgrade automatically (and if this is something like the go-gnome scipt provided by Ximian).

Furthermore, can we build weekly APM Packages (or even instantly, if something has changed in the CVS tree), so we could upgrade to a new release once it is out. And add an update daemon, which would check for new versions of installed packages and send the admin a notification email with "One-Click" (TM) upgrade link.

Please bear with me if this is already in place and I'm just stupid not to have found it.

Collapse
Posted by David Kuczek on
Simon is absolutely right that we will need bleeding edge sooner or later, but I think that we should focus on getting out a solid, scalable, almost bugfree version that offers maximum functionality and ease of use first.

I don't know how we will manage this, but we should have detailed information on package/core development:

- What has to be done (bug fixing, enhancements, new features, database support)?
- Who is doing what at the moment?
- Who wants to do what in the future (until when)?
- A ranking of packages. Which package is mostly done + a reference package and which package still needs a lot of work? Which packages will be abandoned (+why/when)?
Collapse
Posted by defunct defunct on
I don't really see the two things as mutually exclusive.

Plus, we must be midful of the 80/20 rule. i.e. most of the effort goes into the last 20%, but clients, by and large are more concerned with the initial 80%. In many respects, by being a start-point toolkit, the ACS has been a good exemplar of this.

Much as eleminating all bugs (were this possible) is an admirable goal, its going to lead to stagnation and a stunted development path. The mix is *very* important.

Collapse
Posted by Malte Sussdorff on
Well, we are talking about the 4.6 release, aren't we ?

We have given the world a revolutionary cool and new product (OACS 4.5) with multiple database support, stable version of the good starts AD has made, and new development of all the stuff that wasn't good. The next release should be more about stability than about new features. I dont want us to go down the road, where we drag some bugs with us in the toolkit all the time and then they will be assimilated as normal behaviour.

BTW, bugs also mean bugs in the UI. If a page just doesn't work like a normal user would suppose it to work (either because of language, misleading links, badly formated form {like ask for first name, address, last name in this order}).

I see a 4.7 release end of the year which incorporates all the stuff we have developed on in the various projects (dotLRN, Greenpeace CMS, AD sharenet [okay, might be just wishful thinking], full internationalization support). And who is stopping anyone to add really cool other features (aka packages).

IMHO we should have two kind of releases. One release (e.g. odd numbers) which introduce mainly new functionality, but is not thoroughly tested (e.g. because it was written, but no client has used it in production). The even releases would focus on fixing all the bugs found in the odd release, once it has been given a stress test. I'm not in favour of weeks of in-house testing. Once it works as it should in a well defined, no all including, testcase, release it. Other people will find bugs and urgent enhancements you never thought of.

Just my $0.02

Collapse
Posted by Claudio Pasolini on
I'm not sure if this is off topic, perhaps this should be included in the Aolserver wish list, but I think that the we urgently need a standardized way to access and expose web services via SOAP.
Collapse
Posted by Don Baccus on
Regardless of how stable the dotLRN port to PG is, the new portals package really needs to be in our next release.  So I agree with Malte, at minimum that piece should be in.

Regarding Simon's comment ... I look at our 4.6 release as being a pretty modest effort to stablize what exists, hopefully add dotLRN elements (at minimum the core changes needed for dotLRN - one reason we need to move quickly is that dotLRN doesn't work with 4.5), and again hopefully internationalization.

As far as "whiz-bang no one else is doing this" work ... if we could provide internationalized packages translated to a couple of languages that would put us a leg up on any open source web/db toolkit I'm aware of.  I know it would sure attract the attention of many folks in Europe, that point was hammered home at our meeting in Amsterdam (you should've come, Simon, England lost anyway ...)

Let me stress that there's no intention of letting a 4.6 release drift for months, either.  We need to set some firm goals, execute, and roll the sucker out the door and move on.

I think "4.7" will be the release in which we can realistically discuss "whiz-bang" cool stuff.  Of course any one wanting to work on something cool immediately is more than welcome to do so ...

As far as the comment regarding SOAP ... this would be a great little project for someone to work on.  It's modest enough so that such work could be integrated in 4.6 if it happened soon enough.

A side note - ex-ArsDigitan Jeff Davis has been bug-bashing like a fiend the last few days.  That's really great. If anyone else has the time to do so and wants to join in, e-mail me and I'll get folks in touch with each other.

Collapse
Posted by defunct defunct on
You're right... should have attended.... I think my little trip to Japan must have jinxed things... and after I payed all that lolly for the damn tickets... hey ho...

How about an OpenACS, International ticket sales system... given that absolute fiasco the Japanese made of it ;)

Collapse
Posted by Dave Bauer on
Check out this thread: https://openacs.org/bboard/q-and-a-fetch-msg.tcl?msg_id=0005Bz&topic_id=11&topic=OpenACS for a plan to get SOAP support in AOLserver and OpenACS.
Collapse
Posted by Dave Bauer on
I think we need to decide what packages are part of OpenACS and which are optional. Then we can break those packages out, and allow seperate development and release of packages. The optional packages will have to be tagged for which versions of OpenACS they work with.

Having a basic core, makes it easier to focus on the parts that are necessary for a 4.6 release.

Collapse
Posted by Don Baccus on
This only awaits our having the download package available so that we can maintain a reasonably decent repository of packages, which requires our having the basic OpenACS 4-based openacs.org site up and running.  Supposedly a new round of folks are fired up to make this happen, or were when I left to help launch the Greenpeace site ... is this still true?  Are we going to get movement on the OpenACS 4-based openacs.org issue?

I don't want to try to maintain separate downloads on the current site because we don't have an adequate tool to organize them.  Once we get the new site up we can easily unsynchronize releases of the core set of packages and everything else.  Then we can better distribute the management load of maintaining and releasing non-core packages, which would certainly make my life easier.  The lock-step approach we've been taking, forcing everything to release at once, is a PITA.  I think 4.6 will all come in one big lump but I want it to be the last release of this sort.

Collapse
Posted by Malte Sussdorff on
If we have a consistent way for distributing packages, we can say that the bare minimum needed to install other packes would make up OACS (basicly the stuff that you need for getting up the OACS installation, like core, templating....). Which would make the download even more slick. Oh, and did I mention, SuSE thinks about building an RPM to take OACS on its distribution.
Collapse
Posted by Jun Yamog on
I agree with most of you guys
  • make 4.6 more of a stability and polishing release.
  • make some of development guide, like standard UI, guide on developing packages, guide on extending the data model, etc. So that in the future the packages can break free of the core with good guidance.
  • put in new features that is being used on other projects like dotLRN.
  • remove or merge some packages.
Down the road like 4.7 maybe we can do this stuff
  • Moving back the datamodel closer to relational data model not this pseudo object model. Though it has benefits but I think making it more relational will also make the Tcl thinner. In CCM it does make sense to make it ala object model. But I think the power of aolserver and OpenACS is the database object model. We will probably just use Tcl as a layer to abstract the different databases.
  • Have the packages output a uniform HTML or XHTML, standard have to be set. And have the subsite template either parse it or tranform it. This way packages can drastically look different from one instance to another.
Collapse
Posted by Don Baccus on
I would like to make the object model more streamlined, no doubt about that.  But I think the basic idea is sound.  You go on to say that the strength is the object model so ... are you suggesting we move away from pushing so much into PL/SQL perhaps?  Moving more of the API into the Tcl layer would lead to more shared queries and dml statements, no doubt of that.

Could you clarify your comment just a bit?

Collapse
Posted by Jun Yamog on
Hi Don,

Yes streamlining the data model.  I am not thinking of revamping it drastically.  Maybe it just the way we got it from aD.  There are concepts of inheritance, objects, blah blah blah.  Its too object oriented thinking that makes sense on Java not Tcl.  But I think we should go away from that thinking and concept.  Like a cr_revision inherits from cr_items which inherits from acs_objects.  That's just cr_revisions is related to cr_items which is related to acs_objects. That way we can also remove some objects on acs_objects because there is no relation needed.  Why would you need to put an acs_object for a cr_item and cr_revision?  Does not make sense if you think relational.  They are related anyway... so join/relate them.

Maybe if we think more relational we can streamline the data model that suited for aolserver and tcl.  We can probably market the toolkit as tried and true solution, using relational model which has been tested for over 30 years.  Ofcourse that may have a side effect of being a unsexy platform.  But I think currently we are unsexy but sure kicks butt.  I hope some marketing guys can help out on this if this is a good choice.

Im sorry if I keep on bringing up CCM but somehow I am bound to compare them with OACS since am working on both.  Well in CCM they use Persistence Data Layer.  This is to simplify the complexity of the data model underneath so that other developers may not be aware of this.  Do you think SQL and relational model is hard to understand?  I think its one of the easist data modeling to understand.  But it will get difficult if we move away from the very essense of relational data model.

I am not saying the current data model sucks, I think its great.  But we can make it greater if we streamline it with the thinking of relational not object oriented.  Of course a lot of the community members has to agree on this.  This just my opinion.

About moving more code from PL/SQL to tcl that would be good if it makes sense.  Because less PL/SQL means less effort in porting.  CCM already tries to do this.  There are less than 10 PL/SQL on the core data model.  But PL/SQL makes sense too since its faster and more simple and I don't want to fatten Tcl.  Since is mean to be glue.  So I guess I don't have much opinion this.

What I mean about more Tcl api on db stuff it that move the sql calls from www/tcl to tcl.  That should make www more simple for beginner developers.  Plus the fact advance developers will logically think of making their sql reusable.

Collapse
Posted by Malte Sussdorff on
Concerning the streamlining and marketing effects. I think noone is marketing the Object oriented approach in the datamodel. I think it does not make sense to market it either, as this would clearly show the break of technologies (object oriented datamodel on a relational database using an imperative language).

Technology wise, well, streamlining sounds great, but who is going to do it and will it make development easier or harder ? Not to talk about migration scripts. Maybe something we could look for in Release 5.0 {the branch with streamlined datamodell and full webservice support interfacing and providing .NET services as well as Java ONE (or was this something else, I sometimes get lost in all this marketing...)

As for TCL vs. PL/SQL. Only select what you need from the database using as few queries as possible. And try to stay away from PL/SQL while doing it. Reasoning:

- Performance. On aiesec.net, the database is the bottleneck, especially the PL/SQL functions sometimes take a nasty long time. But how do you run the database on multiple servers to distribute the load? Distributing AOLserver is not a problem (and you dont have to deal with fancy caching mechanisms, if the database is not the bottleneck anymore).

- Performance II. TCL 8.4 got a performance boost. This means some queries (I think the if statement and the string compare, to name a few) have been made faster by roughly 50%. Looking forward to AOLserver 4.0 for that.

Collapse
Posted by Jun Yamog on
Hi,
<p>
I don't think we should look into drastic changes in 4.6 as I think most think that way too.  My opinion to streamline with the thinking of less object oriented since this is not the strength of Tcl, aolserver and SQL.  We have made 4.5 great!  Since aD is gone then its up to us to steer the code.  The community has to agree where to go in the long term and short term also.
<p>
My vote for short term is:
<ol>
<li> Make 4.6 a polishing and bug fixing release.  Add in functionalities of working projects like dotLRN.
<li>Streamline the data model a further with relational in mind.
<li>Write development guidelines (this should carry us to the next release).
<li>See if core can be broken away from packages.
<li>Make it short and sweet.
</ol>

<p>
My vote for long term:
<ol>
<li>Streamline further now involving the tcl, packages, etc.
<li>Remove layout on packages and move the layout to portals or subsite template.  An idea is to have packages output very simple yet standard on all packages HTML and have the portals and subsite template put in the layout stuff or even transform it.
<li>Add more service contracs.  Like have permission service contract where LDAP will store the user, group and perms.  Semi core modules are in service contract like CMS, where you can choose the CMS of choice.
<li>.net? web services... I don't think we have to wait for that the next major release may not yet have those things running real things.  Unless there is a project that made use of web services.  I think in the future new features will come from projects.
<li>Official support for multi data store.  Say bboards is stored on another db.
</ol>
<p>
I believe Malte is correct.  We should move more PL/SQL to Tcl.  Now that he have said it my opinion is to move PL/SQL to Tcl for scalability reason.  So lets streamline further the data model and move PL/SQL to Tcl as a general direction.

Collapse
Posted by Stephen . on
Can you give an example of how you plan to streamline the oo-like features of the data model, and which pl(pg)sql you plan to turn into Tcl?  It's quite a fundamental change in the toolkit so I'm just wondering what these abstract suggestions would look like in reality.  Cheers.
Collapse
Posted by Jun Yamog on
Hi Stephen,

Although this are not well though of this are just examples.  As I have stated above lets take for example cr_revisions.

Currently for each cr_items we put it in the acs_objects because its suppose to inherit it.  Of course a cr_item can't survive so you have to have a cr_revision for it.  This cr_revision is again registered to acs_objects because of this so called inheritance.  Why not just relate the tables.  a cr_revision is related to cr_item which in turn is related to acs_objects.  That should reduce acs_objects to real objects that needs to be related.

As for moving PL/SQL to Tcl.  Malte has pointed out because of scalability.  I have never though of this see by older posts above Malte's post wherein I said "I have no opinion about this".  After Malte's post I had an opinion same to him, because his opinion makes sense to me.  Maybe an example is looking for the title of a content item.  See etp__get_title PLSQL.  Its simple enough with only 1 to 2 queries but lots of if and thens.  Now it would not be bad to move those in Tcl.

Again the examples above is not well though of.  They just serve some possible concrete examples.

Collapse
Posted by Stephen . on
So your not saying that the oo-like features of the data model should be changed, but that some of the things we'd like to model do not need to be acs objects, like revisions for example?  How will we workflow revisions, permission them, or keep track of who created them?  What's the problem with the way it is now anyway, is it too slow?

I wouldn't be suprised if re-writing etp__get_title in Tcl made it slower, keeping in mind that plpgsql procedures have their query plans cached.  Most of the plpgsql in the toolkit doesn't even contain any procedural code, being a simple wrapper around one or more dml statements.  Sure, we don't want to do alot of processing on the db side, but I don't think there's many places where we do (and a couple of 'if' statements don't qualify, IMHO).

Collapse
Posted by Don Baccus on
Lars and I have talked about the fact that both revisions and items shouldn't need to be objects. On the surface this seems very attractive, but ...
  • A cr_item should be an object so we can assign permissions to it. ACS 3 had a funky relational table containing pairs as the permission key. This was awkward to work with and having a single object space that permissions works on is a real advantage, IMO
  • acs_objects contains the basic audit information you want to keep about an item (creation date, creation user, etc). If revisions aren't an object you lose that. It could be replicated in the revision itself but we don't want to start duplicating such stuff again ala ACS 3. After all duplication of effort to continuously replicate basic stuff like this in ACS 3 was one of the motivations for creating a common table to hold it all in ACS 4.
And inheritance is a very useful thing to have. In regard to the content repository, I think a better Tcl API would make it easier to use (I always write Tcl API procs for my custom content revision types) and judicious caching will erase any performance concerns.

PL/SQL ... nearly all of the selects in the system are done from Tcl, so we're not getting much benefit from the wrappers that are there now. insert/update operations are always comparatively slow so caching plans for them isn't a big win plus the plan for a basic "insert" is so simple that Oracle won't take much time generating it. As Stephen points out most of the various PL/SQL functions just wrap simple DML statements - they don't really provide a significant abstraction layer, they just make porting harder.

Collapse
Posted by Malte Sussdorff on
I had a talk with Dirk (sharenet developer) about the use of ACS Objects. What is bad about using ACS Objects as a reference table to the actual tables? We even thought that it should be possible to have acs_object_<package-name> views which could be used for all package related stuff. And all services could either use a Meta View (acs_objects, which stretches over all package views) or implement their own strategy. I never felt very comfortable with the idea of having million objects in one table which will be queried all the time. But if it works, why change.

Another idea that came up, instead of splitting up ACS objects, why not store even more information in it. Minor attributes of objects (e.g. like an urgent_p for bboard postings) could be additional columns to acs_objects, having a NULL value if the object does not have this attribute. According to Dirk indexes will internally drop the NULL columns, therefore not resulting in a speed loss.

Well, maybe I should have joind #openacs and discuss the stuff before posting, but it's late out here and I didnt want to loose these ideas before going to bed.

Collapse
Posted by Roberto Mello on
Don,

Dave and I have been working on moving openacs.org to OpenACS 4.5. We moved all the users already and were working on moving the bboards and bboard posts, but we bumped into the driver installed on openacs.org being an old one that didn't escape things properly (oops).

But we'll get the new driver up there and get it rolling. We've talked about using forums instead of bboard (what do folks thing about this?), but I don't know how is the port to PG going, if it depends on anything on the devel branch, and we'd have to come up with new migration scripts (someone I can't remember wrote the migration scripts for bboards).

We'll document how we did this move so others can benefit.

Collapse
Posted by Jun Yamog on
Hi,

Regarding the OO style db.

I think you can still derive the permissions of the cr_revisions based from the cr_items perm. Same for the auditing stuff but you do loose a lot of info regarding the individuality of the cr_revision since everything is tied into a single cr_item. Also you will need to join 3 tables rather than 2.

As pointed by most of you OO has lots of benefits of it. I don't want to revamp the current datamodel but would like move the mindset towards more relational (old tech) model. That is just mindset so hopefully when streamling and making changes to the datamodel it would be closer to what RDBMs was for rather than going farther away from it. Our mindset is not set on OO but since the tool was inherited from aD which seems to be in an OO mindset for 4.x platform and maybe we might continue on that OO mindset. I wish we would not.

Currently I don't have problems with stuffing all things in acs_objects as other projects do it too. Like mmbase data model and of course CCM. But the problem that I see is complexity. Right now we may think yeah its not complex and tell read the docs. But we are familiar with it already. So the only concrete problem that I have seen in the OO db its the learning curve for new developers that has no OO background.

In 3.x is was easier for a new developer to get him/her up and running in a matter of days. The only problem with 3.x is the massive array of tables. But you could work on 2-3 tables without thinking of others. I am not saying we move back to 3.x, this just an example. Because in 4.x I found that most developers gets a harder time because of the massive array of data models, you deal with table that are related but you don't know why, tree_sortkey.

The way the other projects deal with those complexity is to have an intermediate data model. CCM = PDL, mmbase - builders. The new developers coming to this projects already have a OO mindset since they should know Java. So I think if we have a mindset of relational rather than OO decisions will be made that will be closer to RDBMS. Tcl is not OO happy too.

OO mindset is disaster for us in the future because:

  • None of our tools are OO happy, RDBMS, Tcl, aolserver C. We are bound to out grow those tools if we use them for not what they are.
  • Tcl is meant to be thin not thick. Having complex data model may make us code Tcl thicker for new developers coming in to OpenACS.
  • There is a good chance that a new developer coming to OpenACS has no OO background or does not like OO.

Moving PL/SQL to Tcl

Nope we are not moving all PL/SQL to Tcl but we should atleast move PL/SQL code to Tcl if we can. Though it maybe slower at times but I think I still agree with Malte regarding offloading the DB and just add aolservers. Also that think that will make porting easier.

In short

My opinion is to have a relational mindset regarding moving forward the data model because our tools are not for OO and its less complex for new non OO developers. We move PL/SQL to Tcl if we can.

Those are just my opinion but I the end of the day the most important thing for us to have a direction to follow. If its same with your opinion or not we must have direction so old and new developers will do the same. It would not be good if developer A does the opposite of developer B. This is so evident on how ACS 4.2 Tcl was done. Each developer has his own way of doing things. I for one is guilty of doing things opposite because I just followed the original authors because there is no general direction.

So we must agree or follow on what direction to take but in the mean time since we are still thinking about I will continue to voice my opinion.

Collapse
Posted by Torben Brosten on
As a developer-in-training who missed the boot camps, I agree (as much as I understand) with Jun Yamog's statements about 00 versus RDBMS. RDBMS's benefit over OO from less complexity (greater performance characteristics).

Isn't OO's strength mainly for developing systems that evolve gradually and incidentally, whereas RDBMS strength is in a stable structure (if well planned prior to development)?

Collapse
Posted by Torben Brosten on
To further the discussion...

It seems that the situation calls for an RDBMS for serving dynamic pages fast, and an OO system for managing content (and revisions) prior to the content being served "live" from the RDBMS/OpenACS. That's two different systems for two different purposes.

[Hmm.. maybe that is what's happening and I just didn't get "it" until now... or maybe I got it before and just forgot in the confusion???]

[Thinking outloud futher...] then objects are either 1. converted to file-references in the DB and content served from files, or 2. content is imported to the DB then served...

The questions become: When to convert or import? and How to standardize these processes in the new version???

Collapse
Posted by Jun Yamog on
Hi Torben,

Currently there already this system in place.  And you don't need OO to make it work.  The basic way to get content in is to create an acs_object then a cr_item.  After that create an acs_object then a cr_revision.  The are also content repository api for this.  You may also want to start reading the doc of content repository in particular the data object model page.

http://youopenacssite/doc/acs-content-repository/object-model.html

Then look at how file-storage or etp and study how it puts in content to the database.

As for getting it out its just a matter of selecting the cr_item and cr_revision.  Or better yet use some Tcl API what DonB has wrote in particular cr_write_content.  Its a matter of getting used to the data model and api, after a while everything will make sense somehow.

I hope we can move the code easier for new developers coming in.

Collapse
Posted by Torben Brosten on
Jun Yamog, thank you for confirming my understanding of the CR system as I "somehow" assimilate the docs, board discussions etc. And thank you for  considering the importance of decreasing the learning-curve for "new"  developers (for version 4.6)! [--as well as internationalization and the other important points discussed.]

I'm looking forward to reading the CR/object model docs. I'm hoping to help convert the "mental osmosis" of learning the content repository and other parts of the system to more direct methods of learning from reading docs. Right now I'm still focused on the beginners guide --The writing is slow, but progressing.

Collapse
Posted by Tom Jackson on

Both databases OpenACS supports are relational, and the language used to talk about the datamodel doesn't change that fact. The OpenACS datamodel is relational. What that means to me is that it is a very fluid object model. Any row from a select query is an object. Any row from a table is an object. Objects in languages like Java are fixed and require programming effort to create. In an RDBMS, the super object is the entire database and the SQL language. You can use the methods of the SQL language to extract parts of the data, to change the data and to create new data (objects).

What PL/SQL does is to extend the methods that operate on the data, maybe simplifying the interface to the database. In the case of creating an acs_object, the __new procedure handles quite a bit of effort. If this effort were moved to the tcl layer, the porting effort would extend to every page that called the __new procedure. Instead of one change, potentially many would be required.

For me the most time consuming porting effort seems to be the select queries. The join syntax for Oracle and PostgreSQL are significantly different.

If standard PL/SQL and plpgsql packages were used for create, update and delete operations, most of the pl could be auto generated. All that would be left to port would be special operations. These special operations could be moved to tcl procedures, which could perform the operation in tcl or simply wrap a pl function.

Collapse
Posted by Jun Yamog on
Hi Torben,

I don't think anything drastic will happend in 4.6 that would significantly make the learning curve easier.  I have also stated that its 4.7 or down the road, also its just my opinion and there is no real decision on this.

Collapse
Posted by Stephen . on
I don't think it's possible to implement the features we have with our current 'OO' style, everything-references-acs_objects data model such as extensibilty and generic services in any other way.

Defining (and redefining...) acs_objects as a view over many other tables just wont work, PG's native OO features are broken (and both would just move any performance problem to a different set of queries),  and if we're to go back to the ACS3.X way of doing things we should just start developing the old code base again.

I like the direction of Malte's second suggestion, and think the toolkit should be developed with this in mind:  our object system is important but not free;  acs_objects should be used extensively, but inheritence hierarchies should be kept short;  the core acs should aquire more features;  when the core lets us down it should be fixed in the core, not worked around in umpteen packages.

Collapse
Posted by xx xx on

What I would like to see is:

  • to have UI's improved. From my point of view, a flawless group/user admin out-of-the box is essential
  • to have 'bugs' fixed. So OpenACS will work better 'out of the box'
  • to have packages 4.x not depend on packages version 0.1d

I agree:

  • focus on stability
  • focus on user-friendliness
  • introduce new features with uneven releases only
  • put the multilingual feature high on the priority list. It is a feature that is also useful for local sites in a multicultural environment.
Collapse
Posted by Dave Manginelli on
This one is "out-there," for version 4.6 or even the foreseeable future but it sure would be handy...

How about a web-based spell checker tied into the forms API so that arbitrary text fields could be tagged as "spell-checkable"?  I remember reading once on the old AD site that someone had written a cgi script to use the aspell library, but I never saw any code.

With all the work being done on dotLRN and CMS, it seems only natural that folks submitting home-work and/or content would appreciate this feature.

Collapse
Posted by Dan Wickstrom on
I recall that the customer service portion of ecommerce used to have a spell checking feature.  I think it was used in the forms for spam or notifications.  It could be readily adapted for use in openacs-4, and modifying the forms api to make form items checkable should be pretty straight forward.
Collapse
Posted by Don Baccus on
What PL/SQL does is to extend the methods that operate on the data, maybe simplifying the interface to the database. In the case of creating an acs_object, the __new procedure handles quite a bit of effort. If this effort were moved to the tcl layer, the porting effort would extend to every page that called the __new procedure.
Far too many of the "__new" functions for types merely call "new" for their base type then insert into their table. An alternative style is implemented in the CR using the input views, which work both in PG and Oracle. These allow one to simply do an INSERT on your content type's input view to create a new revision. In fact that's how the automatic new revision generator found in cms/tcl/formprocs.tcl works. It's in the Tcl layer and rather than increase the porting effort, the same INSERT works in both PG and Oracle (and in this case happens to be automatically generated from the content type, even better).

Many, many PL/SQL functions in the toolkit are simple wrappers around simple DML. They really don't provide an abstraction layer for the most part. Some do of course and those that do aren't the ones I'm talking about.

Regardless ... I want to move to a higher-level description of OpenACS object types anyway. I get tired of writing code for both Oracle and PG that could be automatically generated for me.

Collapse
Posted by Jun Yamog on
Hi Don,

Wow I did not know about that insert view on CR.  I better check that out once I get back on OACS.  Anyway I don't think we should do something drastic on 4.6 but down the road we need a direction.

I will give a first hand experience as an example about the PL/SQL issue.  I wrote a plsql api one of my project.  Just because I thought it was correct and faster than tcl.  The api deals with copying one revision to a new content item.  It deals with some ifs here and there, well basically lots of logic inside the plsql.  It  sure was handy just to pass in copy_item(from_item_id, to_folder_id).  But at the same time I could have done it in Tcl.  If Malte's opinion was taken as a direction I would have done mine in Tcl rather then PL/SQL.  Well basically we need a guideline/direction so we don't use our own unless there is compeling reason to.  Not for 4.6 but it should start from 4.6 since OACS is now fully community driven because aD does not exists anymore.

Now IF (big IF) the direction was to move applicable PL/SQL api (not ALL) to tcl.  For example my api that I have done is used in most pages.  What we could do is flag the current PL/SQL api as deprecated and make a Tcl copy_item "from_item_id" "to_folder_id".  Both api will exists for sometime until all dependent packages have moved to the new API.

The same is true if the opposite direction is to be done.  Move Tcl code to PL/SQL.  If there was direction to do this then I could have wrote some of my Tcl api to PL/SQL.  We really need to give our opinions about our experiences in 4.5 so can make good decisions on what direction to take.

Or maybe we can make guidlines say for example on all DML operations like "foo_new" must be written on PL/SQL.  Any operations that selects, if, select, if, return must be written on Tcl.

I think for those guys that could meet like what happened on internationalization should meet about this general directions.  I think this meeting will be very productive than using the bboard.  Then like internationalization you guys can post what happened and the community can make inputs.

Only simple and fast general directions that is agreed on must be implemented on 4.6 so 4.6 is out of the door.  Other stuff must be done on next releases.  What do you guys/gals think?

Collapse
Posted by Dan Wickstrom on
Don, Have you made heavy use of those views in the pg version?  When I ported them to work on postgresql, I had some doubts as to whether they would be reliable, since they depended on the dynamic creation of views.  In addition, to handle the insert on the view, a rule is also being dynamically created.  I spend quite a bit of time trying to break them, but in the end, I declared victory and moved on, but I still had some nagging doubts afterwards.  It would be good to know that the pg version is reliable.
Collapse
Posted by xx xx on
If it isn't out there (at least I didn't find one yet), another thing I would like to see in 4.6 or the next version, is a 'Tables browser'.
Reading descriptions of tables could be very helpful, while trying to understand the datamodel of OpenACS.
There are neat descriptions for Procedures and we want them for Packages too, but could we have them for Tables also?
Presently, it is hard to understand how all tables of the datamodel work together.
Collapse
Posted by Don Baccus on
Have you checked out the schema-browser package?
Collapse
Posted by xx xx on
Good point. I didn't check..., sorry. This package helps a lot.
Maybe it should be installed by default for guys like me... ?
Still, it would be nice to have the information extended, with an extra description/sentence, that tells me about the intended function in the datamodel (or is it there too)?