The Web Services and Context Core Initiative (WSCCI) aims to transform Drupal from a first-class CMS to a first-class REST server with a first-class CMS on top of it. To do that, we must give Drupal a unified, powerful context system that will support smarter, context- sensitive, easily cacheable block-centric layouts and non-page responses using a robust unified plugin mechanism.
Be sure to read the roadmap overview.
Code can be found in the WSCCI sandbox.
Hot issues
Active issues where we need help:
- Drupal Kernel Patch: This is priority one, based on Symfony2.
- Use Symfony2 session handling: We'll need to improve Symfony2 a bit in the process, too.
- WebSockets: How do we do that in PHP? Or do we?
Key discussions
Important discussions for background:
Recent discussions
March 20, 2012 Drupalcon BOF, Semantics: What is a 'page'?
In this BoF we tackled the job of clarifying for ourselves the meanings of 2 words that are commonly used in discussions around Core Context UX. The words were 'page' (what is a web page?) and 'context' (how many ways is this word used?).
To do this we split into 2 groups of 15 or so people and recorded our findings. Here are our notes for the 'page' discussion. The 'context' discussion is documented at http://groups.drupal.org/node/218904
(MK: Thanks go to Miro for volunteering to capture everyone's thoughts as we went around the table.)
Notes:
Read moreWSCCI status update - Next meeting 2012-02-28
This week we'll be looking at the finally-not-just-proof-of-concept code that neclimdul and Crell have been working on! It's actually coming along surprisingly well.
I highly encourage everyone to do some homework before this meeting. You'll want to look at the kernel branch of the WSCCI sandbox, which you can download from here:
http://drupal.org/node/1260830/git-instructions/kernel
Read moreWSCCI Status Meeting - 2012-01-31
Introduction of Page Controllers into Drupal
There is a special page that describes what Page Controller is and how it can be used: http://drupal.org/node/1389042
I would like to suggest introduce the Page Controllers for all core modules.
Each controller class could use a namespace. For example if module name is "foo_bar" and the page controller name is "MyController", the namespace would be "FooBar" and the class name would be MyController, so the full class name would be \FooBar\MyController.
Moreover I would like to consider to use following structure for module directories:
Read moreWSCCI Status Meeting - 2012-01-17
Context UX – use cases
(After two hour skype call with Larry discussing Pages and Components, we came up with these use cases to do UI sketches for)
- "Here's an admin form for configuring a view for this" *
For the DX in providing admin UI for all this, this means coding/configuring the response rules for a given path. Where response rules boils down to providing forms that let people do such things as:
- I want a request to node/nid/history (with request type HTML) to be a list of teasers of the revisions of that node (nid).
Rethinking WSCCI
About a month ago, the WSCCI team posted a core patch for the new Context API we've been working on. As predicted there was a fair bit of feedback, much of it resistant. A number of responses essentially felt that they could not tell if the new API was over-engineered or not as they had a hard time understanding the use case for much of the functionality that was built in, such as the "stacking" logic or nested context keys.
At the WSCCI team meeting on 6 December, we decided to take a step back and experiment a bit to see if we could demonstrate the need for that functionality with a quick'n'dirty simpler implementation. I volunteered to try to make such a demo using the Pimple dependency injection library (which was already reasonably similar in concept to the Context API as we had implemented it).
However, after some additional research and discussion with Symfony2 folks I realized that what we were trying to do... Symfony2's component libraries already do. After a long weekend of experimentation, I am actually ready to suggest taking a different tactic, somewhat as suggested (coincidentally after I did most of the experimentation) by Dries.
In short, I propose that we cut to the chase and port Drupal to Symfony2's HttpKernel library, and accept the rather drastic changes that will result.
Read moreCanonical Entity representation
One place that the Web Services and Context Core Initiative (WSCCI) and Configuration Management Initiative (CMI) overlap is the need to have a standard, canonical format to represent nodes and other entities in non-PHP and non-SQL format. There are a number of places where that is useful:
- Including entities in exported configuration, or in configuration files.
- Taking a content snapshot in some form other than an SQL dump file (which, you know, kinda sucks for mose uses).
- Transferring a node from one site to another for content sharing purposes.
- Aggregating content from many sites together for improved searching and cataloging.
- Exposing Drupal content to other non-Drupal systems. This is made easier by using non-Drupal-specific formats.
These are all problem spaces that exist in Drupal 7 now, and did back in Drupal 6, too. Various one-off solutions exist. For Drupal 8 we should have a better universal answer to this question, and be able to build common tools to support it. Those can, and should, also influence our API design to help improve external integration.
Read moreFeedback on the Plugins API after converting Field API widgets
As I announced in the WSCCI Plugin Sprint Summary discussion, I started to play with the current state of the Plugins system ('wscci-plugins' branch in the WSCCI sandbox), and ported the "Field Widget" part of Field API. Code is in the 'wscci-plugins-fieldapi' branch, and is fully functionnal. The job was a no-brainer for a large part, which is probably a good sign about the concepts and current state of the code - yay to WSCCI and CTools folks !
Read moreWSCCI Status Meeting - 2011-12-06
It's time for another pow-wow on WSCCI! This week the main topic will be the ongoing reviews and discussions of the Context API. There's been a lot of discussion lately, and I want us to take a moment to consider the feedback to date and see what our next steps are/should be.
If you haven't read the discussion there, please do so before the meeting so we are all on the same page!
Read more
