We have redesigned the way objects are published and how virtual hosting is handled:
Each object used to have a Publication path that would set the absolute path for this object and all objects inside. This allowed a very flexible layout but could also lead to mixups and confusion if it wasn't used consistently.
More importantly it allowed one user to override the publication of another: if you published something under /hello/ i could publish something else as /hello/world/ and thus block an object called world that you might have had inside of /hello/
This Publication path is no longer used.
Instead, each group or user is allowed to set one area as their public area in the attribute GROUP_PUBLICROOM or USER_PUBLICROOM. That area is then published under the group or username. If the attribute is not set then it defaults to GROUP_WORKROOM and USER_WORKROOM respectively. Thus publishing something as /hello/ can only be done by a group or user named hello. And publishing something as /hello/world/ can only be done by someone who has the permission to write into the container published as /hello/.
Btw: Users and groups are now no longer accessed on /home/ but directly on /.
What may be:
The remaining work mostly centers around making publising more visible. It should be easier to see if an object is published, and where. And also switch publishing on and off. First steps of that are already visible in the (logⁿ) package which sports a tab for each virtual host where a container is published.
Virtual hosting used to be implemented very simple by setting a path that was just prepended to the actual path for each request. The request was actually rewritten and it was not recognizable that a virtual host was effective.
Virtual hosting has been redesigned completely:
A hostname is now assigned to a group or user.
When it is resolved, the group or user object is checked for a public room and the path of the request is then found inside it. If it is not found there, it is checked in the root-room and if that fails too, the first component of the path is checked to see if the group contains a subgroup or has a member by that name.
Because virtual hosting closely relates to publishing, the code to handle this has been made part of the filepath:url module. The functions to resolve a path to an object have been rewritten to handle the new way of publishing and virtual hosting. object to path translation also takes virtual hosting into account.
To handle the latter the Caller module was extended by a function to find the socket from which a request was made. Similar to CALLER, the new function Caller.get_socket() will traverse the backtrace until a socket object is found. The socket is then queried for the virtual host that is to be applied for the translation.
What may be:
Ideas range from automatically setting a subdomain for a subgroup or member, so that each subgroup or member can have its own hostname based on the group or username, to allowing a group to set their own domain.