Forum OpenACS Development: Should an optional service package modify an application package?

1: Should an optional service package modify an application package?

Posted by Dave Bauer on 12/30/03 03:15 AM

I figured out that the file storage WebDAV support implementation should be in a seperate package.

One thing I want to do if have a site-wide parameter for the default behavior for file-storage folders. This parameter would be set in the file-storage-dav package to determine if file-storage folders are WebDAV enabled by default.

I would like to add an after_install tcl callback to the file-storage package when file-storage-dav is installed. Obviously it would be cleaned up if file-storage-dav is uninstalled.

Does this sound like a good idea? Is there any alternative besides having the callback built into file-storage and checking for the existance of an optional additional package?

I think having optional packages that can add features to a core package is a good way to add functionality that might not be needed by everyone.

2: Re: Should an optional service package modify an application package? (response to 1)

Posted by Malte Sussdorff on 12/30/03 09:21 AM

Out of curiosity, why can't the WebDAV package set the parameter once it is installed. I think the behaviour of the additional functionality should be handled by the service package. This is due to the fact that I assume the service package to be useful for more than one application, otherwise it does not make sense to split (for me at least, but I'm more than eager to listen why you want to split).

3: Re: Should an optional service package modify an application package? (response to 1)

Posted by Dave Bauer on 12/30/03 03:03 PM

Malte,

I am not sure what you mean. The paramter should be set by the administrator. Here is the scenerio:

I install file-storage and the file-storage-dav package. I want file-storage package instances to be WebDAV enabled by default so I set the parameter in the file-storage-dav package.

Now whenever I create a file-storage package instance I need to add the folder_id of the package instance to a table to enable the WebDAV support.

One way to do with is with an after_instantiate tcl callback. I could create the callback in file-storage, which would check for installation of the file-storage-dav package, and if it is not installed, do nothing.

4: Re: Should an optional service package modify an application package? (response to 1)

Posted by Dave Bauer on 12/30/03 03:06 PM

Oops,

Or I could have the file-storage-dav package create a callback on the file-storage package. This way it would only exist when file-storage-dav is installed. This seems cleaner from a maintainence point.

The reason there is a file-storage-dav package is that there are some content_type specific operations that are needed for file storage objects. If the default content_folder/content_revision WebDAV operations were sufficient, no additional code would be needed.

5: Re: Should an optional service package modify an application package? (response to 1)

Posted by Dave Bauer on 12/30/03 03:09 PM

Another point. I should think more before I hit confirm.

I haven't worked out all the details for the administrative user interface for managing WebDAV support for content folders. Right now only file-storage has direct support. I am not sure if it is best to leave the WebDAV support up to each package, or probive a site-wide interface for all folders.

It is a continuous design process. I want to get something that works, and then we can evaluate the usability and make adjustments as necessary.

6: Re: Should an optional service package modify an application package? (response to 1)

Posted by Lars Pind on 12/31/03 12:26 AM

Just a quick note that this patterns occurs in other contexts.

I've been thinking of writing a "feedback" package, which would replace the current general-comments and include other types of feedbacks, such as ratings, or any other type of "pick one (or more) from a list of options" type feedback. (Ultimately, this could be extended to do anything survey does - or, obviously, be implemented using survey as some sort of back-end ...).

The UI here would be a link next to the object that says "comment" or "add feedback" or "rate this *object name*".

Another example: I've also been thinking about a list package, which would let users build lists of objects on the site. Sort-of a bookmarks module internal to the site. Think "My favorite books/places to eat/contacts/movies/whatnot", think IMDB movie lists, Amazon shared lists with comments, etc.

The UI here would be a "Add this object to list <dropdown>" widget next to the object.

The current structure would require all packages that want to enable feedback or allow users to add its objects to lists to 'require' the lists and feedback packages, and put the widgets where they want to.

A more sophisticated solution would be to make it optional to install the feedback and lists packages, and the applications know how to check and provide the proper links.

An even more sophisticated solution would be that the links to feedback/add to list automagically show up even in applications that don't know about them, when you install them.

Does this sound related to your thoughts about DAV?

I would tend to opt for the first, very simple solution: file-storage would simply require the DAV package, and if you don't want DAV support, you still have to install the package, but you can disable or not setup the DAV package, and hence not have DAV support.

Does that help any? I'm not sure I understand the details of your problem.

/Lars

8: Re: Should an optional service package modify an application package? (response to 6)

Posted by Malte Sussdorff on 12/31/03 09:42 AM

I think for this to work it might make sense to have a "display" function for each package, that would display the object(s). Onto this display function you could then hook additional items as Lars has described them in point 3. Hopefully there are other alternatives as well.

9: Re: Should an optional service package modify an application package? (response to 6)

Posted by Talli Somekh on 01/01/04 09:33 AM

Lars, have you written up any design docs on the feedback idea? What's the path to its implementation?

talli

10: Re: Should an optional service package modify an application package? (response to 6)

Posted by Talli Somekh on 01/01/04 09:37 AM

Whoops, too quick on the submit and confirm buttons.

DaveB and I were discussing that items like forums really ought to be simply "kinds" of general comments. That is, a general comment is simply a package to attach a forum/bboard discussion to an arbitrary article/object. Why should a forum simply be the creation of a general comment to an empty object? (If I am using the term "empty object" incorrectly please correct me)

Perhaps your feedback idea is taking this conception of general comments and its types to an even higher design discussion?

talli

13: Re: Should an optional service package modify an application package? (response to 10)

Posted by Lars Pind on 01/06/04 09:32 AM

There's no design doc on the feedback package yet, but I think we all agree that general-comments needs replacing, and that we want it to support more than the current general-comments package does, such as:

- anonymous feedback/not requiring login

- not requiring a title

- ratings

- attaching a file

- feedback types/categories

- structured feedback, such as multiple input fields, ratings along multiple dimenions, etc.

On an architectural level, I'd rather implement this as a thin layer on top of CR than I'd, say, "attach forums to an object", or for that matter "attach survey to an object". But I'd rather see the feedback package than not, so I'm not religious about it.

As far as the path to implementation goes: It's not on the top of my list.

/Lars

7: Re: Should an optional service package modify an application package? (response to 1)

Posted by Dave Bauer on 12/31/03 01:22 AM

Lars,

I don't actually have a problem :) Either way will work, I just was wondering what OpenACS developers thought about this.

Generally, I would pick an easy solution. I don't want things to get too complex. What I do want to do is not have so much unused code. OpenACS is complex enough as it is.

Another issue would be if the dav packages were not distributed as part of OpenACS. In this case, they probably will be added to OpenACS. I can imagine an instance where optional features could be added from packages that are not part of OpenACS, so deciding how this might work is a good idea.

11: Re: Should an optional service package modify an application package? (response to 1)

Posted by Dave Bauer on 01/05/04 08:21 PM

Lars,

Actually there is already code that works the way I am thinking, but in a specific context. That is, the dotlrn-* packages have specific code to run when a package instance is mounted underneath dotLRN. This does not use the package tcl callbacks, they didn't exist when that code was written.

The dotlrn-* code only runs when a package is mounted by the dotlrn code, not when its mounted through the site-map.

Anyway, I think its a good idea to consider if we want to build future intergrated applications by combining standard packages.

So a new way to implement the specific package mounting code using tcl callbacks would be to check if the package is being mounted under an instance of dotlrn and if so, perform the necessary operations.

Another solution to me specific problem parmaters that are set for all packages of a package type, or a way to change the default for all new instances of a package.

Even more interesting would be a general way to make more complex settings that affect tables other than the apm package parameters.

12: Re: Should an optional service package modify an application package? (response to 1)

Posted by Carl Coryell-Martin on 01/05/04 08:47 PM

To follow up on Lar's question about general ratings packages and the like...

My preference as a developer is to keep things easy for me. Easiest for me is a scrap of code that I put in the templates for an object that generates the link.

This doesn't require any call backs or magic registration. I just need to decide how the widget should look, where it should go and what object id to pass to it.

--carl