Forum OpenACS Q&A: Photo album for huge image library?

If you choose to build around them then you will most likely end up building an ad hoc solution that approximates what's available in the CR.

talli

So, back to my original question with a little clarificationa and extension. Does anyone have experience scaling Photo Album (or any package based on the CR I guess) to tens of thousands of objects? What if any impact does the number of objects in the CR have on the permissions system? Is it possible to have objects that do not inherit permission and thus grow the object-party privilege map view?

You could save months of work implementing your image repository using the OpenACS content repository. Greenpeace International uses a content-repository based system to manage the image library on their web site, although I am not sure how many images are in there.

Besides that, I think you might find some other interested parties to building such a system for OpenACS.

Certainly there are content sites built using the CR that are more complex than any I've seen not using the CR ...

Many of our development community are happily using the CR so I find your comments somewhat amazing, to be honest.

Keith hasn't even defined the problem completely and everyone chants 'CR'. This is total 'BS'. A standard paradigm is to extend the acs_objects table, more packages follow that paradigm than use the CR. If you don't want revisions hanging around for every object you create, or you don't want to do a few extra joins to get you data back out again, why do you have to do so?

Keith's stated concern is portability. Instead of chanting 'CR' at him, why not step up and show how portability can be achieved, and what the CR can do to enhance his project?

If we want standard tools, they should apply to acs_objects, not items in the CR. This is a general tool, this is a standard paradigm. Then every time we add a tool it applies to everything, because IMNSHO everything in the database is content.

But before something can be called a standard paradigm, it has to be shown it can easily solve problems that are common to the area. So far the examples I have seen, and the amount of work that appears to be required to create them, leads me to believe that using the CR is difficult.

Recreating the functionality in your own package will also be time consuming, so if you need most of the features of the CR you might decide it is worth figuring out how to use it.

You are correct that right now, the existing packages in OpenACS are not the best examples of how to use the content repository. Of course, most of them work, so there isn't as much incentive to rewrite them just for fun.

It is also a good idea to offer general features for acs_objects if that makes sense. One area this has been addressed for 5.0 is categorization, which was previously implemented only for content repository objects.

The greatest issue with the content repository is the lack of a full Tcl api to reduce the huge amount of pl/sql code that needs to be written. The old aD CMS package, which is greatly unappreciated, has some good ideas on how to automate many of the things you are talking about. The user interface is far from ideal so it doesn't get used much. It is more of a content repository browser than a good example of a end-user application.

Lately the outward appearance of OpenACS has been improving. I think we can also improve the Tcl APIs for developers to allow for easier development.

I guess you will have to decide for yourself which one to use. Here is what I can share about minus and plus of CR.

- the documentation is not that good.  But today unlike 2 years ago there are some apps already to study and see how they use the CR.  You can start on file storage, bug tracker (i think) and CMS.  I have a ongoing & unfinished package on contrib (bcms*).

- If you will be developing something near CR like features then might as well help us improve it.  Or just use the CR in some other way maybe some weaknesses or bugs may come out.

- portability I believe it not good.  There are exports and imports but I think they do not run.  I have never used them. Although it is encourage that you can contribute this weakness of CR.  This should be a little easy if the structure of your content is file system like (e.g. folders and files).

- search is also poor.  But its more of a OACS problem rather than CR.  But CR is a little easier since some of the service contract are already implemented.  So its like poor but better... weird :)

- permission scalability.  Its not really CR but more of the general permission.  So an improvement of permission should directly improve CR permission scalability.

- on the start its a bit hard to learn CR but once you are used to it.  Things are a little better.  Pretty much like what is OACS.  On the start is a bit difficult, once you get used to it.  Its ok.

I hope this helps you in your decision making.

All,

The above are just my opinion it may not be 100% fact.  I would like to avoid to have a useless discussion about I like CR and I don't like CR.

With all these happy campers, you would think a few would have released their ideas to the OpenACS community so we could learn from them. Until someone does, why should we be so insistent that Keith follow all the rules and release his code. Are we trying to help Keith, or ourselves here? Just repeating 'CR' doesn't do much to help anyone. Anyway, instead of just saying I am wrong, just point to working examples somewhere that proves I'm totally mistaken. It wouldn't be the first time. Please include with the examples a time estimate: how long did it take to write the package? The fact that it can be done, or that this or that feature is supported is completely meaningless without knowing how much work went in to writing the application, how fragile the code is, how easy it is to modify or understand.

Maybe if a tutorial covered re-implimenting the notes example in the CR and showing all the benefits, how it saves time, etc. that would be a better way of letting someone decide if the CR is good for their application.

Btw, just because something is difficult to use or figure out doesn't mean you shouldn't use it. And once you know it the decision to use it or not for future work becomes easier to make. The biggest benefit of the CR is that it is integrated with OpenACS.

But those gripes are also no good within the context of making the system better, particularly when the choice is to avoid the system completely rather than improve it. The CR can be a very strong aspect of the OpenACS architecture but gets far too much pushback and neglect from those who choose to write ad hoc implementations over and over and over...

talli

I've watched as folks waded into the oacs CM stream over the last two years. Most, it appears, have been scared away by claims of "DANGEROUS WATERS". I'm just wondering why there is so little effort given to producing concrete examples and guidance that would prove the warnings false. Well, actually, I know why this is the case... the guys (and gals) that have taken the time to dig in and understand (the ones that are qualified to dispel the fears) are very much in demand for these exact skills.

I remember not too long ago when Joel revamped/rewrote the Getting Started tutorial that helped some of the basic oacs pieces fall into place for me. And, I'm sure it has helped countless others as well.

Wouldn't it be wonderful if, as  Tom suggested above, there were a simple tutorial (including working code samples) that would help beginning CR users understand the basics? The pifalls? I don't think it would be extremely time consuming for any individual CR expert if each of those knowledgeable of the CR added a small piece to the tutorial.

We do have a CMS forum that's gathering dust. How about a thread in that forum where bits and pieces could be added? If you have coded with the CR, would you post?

If so, just add a message to the thread (https://openacs.org/forums/message-view?message_id=136094) I just created for this purpose!

Now is your opportunity to give a little an receive a lot.