Spaces 7.x-4.x Architecture

Hi Grayside - thanks for keeping up with this!

As mentioned in IRC i want to put the question out there - should the 7.x branch be in sync with 6.x? like - 7.x-3.x?

Basically the suggestion is to use the module version (regardless of core version) to refer to each significant architectural change.

As far as what qualifies as significant IDK... do these changes for D7 include enough conceptual departures to warrant 7.x-4.x (and 6.x would then not be planned to move beyond 6.x-3.x) - if so then maybe that's the way to go?

I second that the module version numbers should be disconnected from the Drupal version numbers. This is the way many modules do it including Views.

EG:
Architecture of 6.3 = 7.3 and a change in architecture would be x.4 in this case 7.4. So if we had create a 7.1 or a 7.2 these would be the same in architecture as 6.1 and 6.2 were. Then other modules that create their own Spaces or extend Spaces could match the Spaces API version number. IE spaces_node version 7.3 would require spaces API version of x.3. This is of course is up-to the module maintainer. So I am suggesting that their should never be 7.1 or 7.2 release unless we want to go backwards and that the next release should be 7.3 matching the 6.3 API and the rewrite should be 7.4.

On the Entity changes part of this discussion, since OG 7 now depends on Entity API. I assume any move towards making Spaces Entity driven will be based on or use the Entity API module. If this is the case I would assume Entity specific Spaces modules like Spaces OG would mostly be focused on UI and some Entity specific features.

Does anybody have any experience or input with regards to the Entity API module?

(subscribe, don't have anything much to add, but really like the Spaces OG Intranet and Spaces OG differenting).

Subscribe.

I don't know if this is a little out of scope for this discussion but I have been thinking thinking about how things could work in the long term 7.x, 8.x, 9.x and how the basic concepts of Spaces work and looking at other existing projects for inspiration and direction. The following is my thoughts on this.

I think Views has a lot of concepts and UI that can be used for inspiration. At a basic level a view is an object with different variations or overrides IE: Displays.

If you had to translate this concept to Spaces a Space would be an single object and each Preset would be like a Display.

A single space would be Entity type/bundle and/or Context specific. Views does this by Entity when creating a View. Panels can also be used here for inspiration as it uses contexts affectively for something similar here. A Space should be able to define multiple Contexts that it would apply to.

Each Preset would then be a grouping of settings for the space. When a space is loaded the relevant preset would be loaded as the active Preset that was associated to that Context/Entity/Bundle. If a direct association to a Preset can not be made but the context of the Space is still met then the space can have a setting ether load the default Preset or to not load the Space at all.

Preset should be ether directly associated to a Entity like it is currently in Spaces or a Preset should be able to extend but not override the Space's context.

Each Preset should be able to be extended with some sort of Plug-in system. An example of this would be the current variables override system. Another would be Features. Allowed Features, the default settings and if they are allowed to be controlled by the user. EG turned on/off.

Another example of a Plug-in could be a field controller that is able to control the value of fields based on the selected Preset. The fields would be hidden from the edit form and the value would only change when the Preset changes. This concept is already currently being used in Spaces OG. I have sort of worked on this idea for D.7 here http://drupal.org/node/1250968

Purl integration could be ether built-in and used with the Context system or maybe developed as a Plug-in. The scope and interaction of something like Purl on ether the Space level or the Preset level is not clear to me.

When it comes to UI I would consider using something similar to Views, Panels or Contexts. A plug-in should be able to add their own UI to the Spaces admin UI. An example of this would be how in Views you can added fields to your view. I can see all the of the above concepts (Variables, Features and Fields) using this same concept. Each plug-in would add its own UI block and allow for items to be added to its list.

The context concept would add a lot of overhead to the first round of development of the concept and maybe initially the simpler direct association should be focused on and Context's added later.

The idea is maybe a little too big for this discussion and if I had the time and skills I would take on the challenge to pursue a large development effort as this, but unfortunately for now all I can offer is my thoughts and testing with maybe a few small patches.

I hope this helps your discussion.

When it comes to the question about ctools or context. I think ctools is the better long term choice, but I am not 100% sure and I don't have enough experience to give any reasons as to why I think this.

@Grayside, I have actually thought quite a bit about this when I was upgrading most of spaces user/taxonomy to D7. I think you are on to something that there should be Spaces and Spaces Entity and then Spaces OG can be things more centered around the "Group" concept. I think there are likely still use cases for having Spaces User and Taxonomy as there are some specifics there that likely could not be dealt with generically but the plumbing for dealing with Entities could be in a Spaces Entity module. I also think it would be a big enough change to warrant a 7.x-4.x branch.

@Grayside
Yes that was a bit of a long waffle, sorry. I posted in a bit of a rush. Here is a sort description to assist with understanding the above description. I will see about actually putting together a better proposal when I get some time if you guys are interested in discussing the idea further.

Idea teaser for #11:
Currently Spaces Presets are grouped by space type. The idea is to change this concept allowing you to create a object/group of Presets for a node type and then create another object/group of different Presets for another node type. Each of theses objects/groups would be known as a Space. This single Space would function as a single object.

The reason I used Views as a comparison is that it has already got a good architecture in place for objects that can be extended with plug-ins and each View object can have multiple variants IE: Displays. Views has also solved the problem of running an object from code and the database.

As a basic comparison to Views in concept and architecture:
$view->display-x == $space->preset-x;
$view->display-x->fields == $space->preset-x->variables;

After the OA D7 bof today, it's probably time to revisit this thread for Spaces 7.x-4.x

Seems I've missed this issue when I opened #1977410: Re-think Spaces module in 7.x
We have some code there :)