virtual hosting

(ˢᵒᶜⁱᵉᵗʸserver) is a platform for building collaborative websites.

(ˢᵒᶜⁱᵉᵗʸserver) is not just a webserver but an object storage that supports HTTP,HTTPS and a number of other protocols like email (SMTP,IMAP) and chat (IRC,XMPP). It also supports a programming API for rich client development. Underneath is a welldesigned object system that seamlessly integrates those protocols directly into native objects. The Architecture distinguishes User and Group objects, Documents, Rooms and Containers, as well as annotations and messages. The REST API allows the server to be used as a BAAS platform, which enables you to build fully functional websites and applications without any backend development.

(ˢᵒᶜⁱᵉᵗʸserver) is licensed under the GPL v2.

(ˢᵒᶜⁱᵉᵗʸserver) is based on ᵒᵖᵉⁿsTeam(pdf), a project by the University of Paderborn in Germany, lead by Prof. Dr. rer. nat. Thorsten Hampel. (Obituary)

Our current focus is the development of the REST API and frontend applications using that API.

If you are interested to know more about (ˢᵒᶜⁱᵉᵗʸserver) or even want to contribute (we are looking for javascript developers and non-technical contributors (marketing, business development, etc)) please contact Martin Bähr at martin(at)realss(dot)com

Author :mbaehr   |   size :1823Bytes   |   Publish Date :Nov/3/19/18:34   |   to Top

sTeams way of handling multiple languages for a document currently works like this:

First, multi-language support needs to be configured by a sTeam administrator by specifying which languages are to be supported in the multilanguage_languages attribute on the admin group object. Once that is active, containers and rooms show an option to configure them as multi-language containers. If this is activated you are able to select a document in the container for each language that was configured above on the admin group.

This is rather suboptimal. Different pages may want to support a different set of languages. There is nothing in offering a certain set of languages that would require admin intervention. The above language list could be a hardcoded list covering all languages on the planet for example, but then we'd get a long list of languages to select in each container.

The next problem is that, in order to select a document for a language, the document needs to exist. So, first you need to create a document for a language, then go to the language setting for the container and select that document. And then better don't try to move the document into another container...

A better approach might be the following:

Throw away the admin setting. Just allow any container to be configured for multi-language use regardless. Then for each document or object even, specify its language, just like you currently specify the content-type. That language can then be reflected in the documents icon.

Optionally, if the container is a multi-language container then register the document with the container as the index document for that language.

With multiple languages, one document should be marked as the original. This document could then be used as a fallback if no suitable language is found. It would also allow marking other languages as up-to-date or not, as those should be newer.

Next, we need to decide if there should only be one document per language allowed, or multiple ones. The later might simplify some things, but complicate others, such as a translation interface which would need to differentiate which documents in each language are related. This question relates to the more general question of handling multi-part documents. A multi-part document would be a container with multiple documents inside which make up various parts, such as header, footer, sections, pictures, etc...

A multi-part document could be edited with all parts open in a separate text area at once, or all parts displayed and each to be made editable with a click. A multi-language document would show the original on top and all other languages below either with tabs or with an accordeon style interface opening one language at a time.

But how would we handle a multi-part and multi-language document? If the multiple parts are arranged from top to bottom, languages can be placed side-by-side perhaps? Put the original language on the left and select the target language on the right. In the inventory documents would be ordered by their appearance for each language.

How to implement all this?

  • Ignore the multilanguage_languages attribute and always allow a container to be configured as multi-language container.
  • Register a language attribute for the Document or even the Object class. (update: there already exists a OBJ_LANGUAGE attribute that appears suitable, it defaults to the language of the user)
  • Add a field to set the language in the object details.
  • Create an interface to edit a multi-language document. Given the above consideration this should probably be side-by-side even if it is only one document. This would also help in case the document is very long as you would be able to scroll and keep the translation always in view with the original.
  • In the admin view a multi-language container should have a direct edit-link to not require entering the container for editing.
  • When displaying a container with multiple articles, check if any containers inside are multi-language containers, and pick the appropriate content. Actually this can likely be done already in the xml generation stage, so that the xsl template does not need to deal with the multiple languages at all.
    • This can probably be done with a get_content() like function that calls get_content() on the appropriate language. For a multi-part document, this would have to concatenate the parts.
    • Ideally, a multi-language container would be able to look like a document in the xml structure. Can we do that? (update: if there is only one object per language we can probably handle this in get_public_inventory() by just returning the appropriate document instead of a container.
  • For a log, order the articles by container-creation time
Author :mbaehr   |   size :5143Bytes   |   Publish Date :May/13/12/14:44   |   to Top

We have redesigned the way objects are published and how virtual hosting is handled:


What was:

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/

What is:

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

What was:

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.

What is:

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.

Author :mbaehr   |   size :3608Bytes   |   Publish Date :Dec/24/11/18:12   |   to Top