Forum OpenACS Development: Any good reason content_item__move function only allows folders as parent?

i think, it would be a good idea to remove this restriction. However, one has to deal with at least the following aspects:

• folders have registered content-types to restrict the types of their children (cr_folder_type_map), other content-items/acs-objects do not have such a map. Not sure, how important the restriction is. i could live without it.
• when the restriction is lifted, essentially, every move operation is potentially a move operation of a tree (like content_folder.move). However, since it is already possible to create children under arbitrary items, i would not be surprised, if there would be already some problems in the code (like operations on looping structures).
• a content-item.copy becomes more or less a content-foder.copy
• the content_folder.is_sub_folder logic has to be extended

Most likely, there will show up more tricky issues when one is working on an implementation.

Essentially, i would think that all logic should be moved from content-folder.* into content_item.* operations, content_folder.* could be more or less stubs for compatibility. I am not sure about the necessity for allowing/supporting arbitrary acs-object-ids as parent-ids, arbitrary cr-items definitely would make sense.

What does it mean, for example, for a content_revision to have content_item children?

The content repository doesn't define any meaning to the parent_id relationship. The meaning is defined by the applications that use the content repository.

There isn't any restriction or problem to having a content_revision as a parent_id, although it could be confusing if the semantics were not documented in the package that used the content repository in that way.