http://openacs.org/forums/message-view?message_id=109480

Here's what I'll propose based on that thread and the current state of HEAD in the CVS tree:

/tcl
/www
/www/admin
/www/sitewide-admin
/www/doc
/www/resources
/lib
/test
/sql/oracle
/sql/postgresql
/catalog



/www/sitewide-admin
-------------------

Files in this directory are intended for site-wide package configuration, pages that summarize across all packages on the system, etc.

The file

SERVICEHOME/packages/my-package/www/sitewide-admin/some-page.tcl + .adp

Will be served for the URL

http://site.com/acs-admin/package/my-package/some-page

This page will only be available to site-wide admins.




/www/resources
--------------

This is for graphics and other files that we wish to serve more efficiently by skipping permissions checking and processing.

The file

SERVICEHOME/packages/my-package/www/resources/my-image.jpeg

Will be served for the URL

http://site.com/resources/my-image.jpeg

They will NOT be processed, e.g. if you put a .tcl file in there, we will not execute it, we will return the source code to the browser in raw form.

They will NOT be served normally through the mounted package, e.g. the URL

http://site.com/my-package-mounted/resources/my-image.jpeg

Requesting the above URL will result in a

403 Forbidden

return code.




/lib
-----

This is for include chunks (tcl + adp pairs), master templates, etc.

It is NOT called /template, because /template suggests that you only put templates here, which is not correct. You can put templates, but typically you would put complete tcl/adp pairs.

The file

SERVICEHOME/packages/my-package/lib/some-template.tcl + .adp

Can be included by the same or another with the following tag in a .adp file:

<include src="/packages/my-package/lib/some-template">




/test
-------

This is for defining test cases for automated testing of the package.

It works like the /tcl directory in that you put files like

SERVICEHOME/packages/my-package/test/my-procs.tcl

and

SERVICEHOME/packages/my-package/test/my-init.tcl

You can watch -procs.tcl files in here.

The only difference is that files in this directory are only sourced if automated testing is enabled for the server. There will be some parameter to handle that.

We're planning to catalog parameters that deal with production versus development/testing, and post a separate TIP with the result.

Now ... vote, please!

/Lars

Now I have to change my convention...

Jeff, I like your suggestion. The reasoning behind putting it under www/ is that it contains requestable pages.

/www/doc and /www/sitewide-admin work roughly the same way, although it's true you can get to the pages through a mounted package.

Hm.

I don't have any strong opinion on this.

/Lars

What is the reasoning to disallow requests of /mountedinstance/resources/ ?

-Roberto

You have to say /resources/package-key/file-name, so that won't be a problem.

If that file doesn't exist, we currently go look at www/package-key/file-name afterwards.

/Lars

The request processor will route the requests correctly if you use "/resources/"

perhaps presenting an inverted symlink tree for www and resources would solve it ?

e.g.

/www/myblog -> /www/instance/packages/lars-blogger/www
/resources/myblog -> /www/instance/packages/lars-blogger/resources

I think then, designers using their tools and selecting image refs from a directory structure won't get botched up...

If that works, it's feasible the package manager could create/destroy the symlinks when sitemap is used to mount packages.

This doesn't address subsites - I haven't used them so I don't know how they work.

I like the idea of /lib, when you have tcl/adp pairs. Has the /templates directory gone away? In any case what is the substructure of /lib or /templates going to be. For small packages this probably isn't an issue. Should each package make it's own internal structure? is it a copy of /www directory wise?