Posted by irakli on May 20, 2012 at 3:11pm
From what I understand, Symfony2 is going to be default implementation for RESTful services. That said, Drupal has always prided itself for providing alternatives.
Can REST implementation be pluggable? Say, I would like to integrate: http://zaphpa.org/ as a REST implementation for D8, should I be able to?
Thank you.
Comments
This stuff goes deep
While there are contrib alternatives for many things in the Drupal world, there's a strong case to be made that things like handling routing and the underlying serialization architecture need to be standardized in core. As evidenced by some of the roadmap posts, implementing routing with any given framework can entail a full rewrite of almost the entire stack of request handling.
That said, it would be interesting to think about whether even the kernel could be somehow pluggable, implementing a standard interface that other components could replace.
I'm curious why you'd want one routing solution over another, however, since at the module level they'd need to be equivalent. Are there particular use cases?
(Disclaimer: I am in no way part of the decision making crowd of this committee, just trying to help out a little. Others can give much more authoritative answers and information as to the overall tech plan).
Not feasible
As ethanw says, we're talking about the core of core; It is not really feasible to swap out something as low level as the routing architecture.
One of the reasons we're using Symfony for these pieces is that Symfony does offer a heavy interface-driven architecture, and we'll be writing our own implementations of some of those interfaces rather than using one of the provided ones (for the UrlMatcher and UrlGenerator, in particular). It may be possible for a particular site to offer an alternate implementation of one of those; in fact I'd hope that will be possible, as it will be a sign that we did it right. However, it would still need to conform to the same interfaces, vis, the Symfony interfaces.
That means a complete replacement of the Symfony routing model with Zaphpa or Lithium or whatever would not be possible. Architectural design is not something that is easy to swap. That said, the Symfony routing design is quite elegant, which is why we're using it. :-)
Larry, Ethan, many thanks for
Larry, Ethan,
many thanks for your kind responses.
I think the danger of closely tying to one solution is: well, what if that solution is not as universally good in all use-cases as we'd hope? It's putting a lot of trust in Symfony2 :)
Either way, to be clear: I was hoping for some pretty high-level, dispatch-based hooks to the extent of Drupal "saying": "hey, guys and gals, I would like to process this request, anybody up for the job?" and maybe collecting the result of the processing in a way of callback or something.
Obviously, implementing full stack to the extent that is being done for Symfony2 for more than 1 frameworks is out of scope, but at least leaving a possibility of overriding would be nice, if possible.
cheers
.............................................
http://twitter.com/inadarei
Still not feasible
At that point you're just adding another layer of meta on top of an existing meta layer. I don't really see the value in that. :-) Once you get a request mapped to your controller though you can do almost anything you want in terms of returning stuff. But making the core routing system itself swappable requires inventing some new meta-routing-routing system for no purpose other than to load a meta-routing system that gets us the routing system... that we're going to be using anyway.
We have to assume a given architecture somewhere. We always have. We're just assuming a new-and-improved one now.
Link to issue
That's actually already part of how Symfony handles a request. So modules will have various opportunities to step in and customize.
But, I also opened an issue for making the top-level kernel object swappable as well, in case someone really doesn't like Symfony's kernel.
Don't forget that the
Don't forget that the Symfony's HttpKernel is an event-driven architecture, totally free of any hard dependencies except the Request (theorically). All events are prone to short-circuiting.
This means that the kernel effectively does nothing more (except some raw logic, but that we can ignore for this discussion) than throwing events.
Short-circuiting means that any listener, attached to any of those events, set up with a sufficient priority, will be able to drop the others.
This means that, in theory, you can set up an early listener, that does YOUR stuff, and force everything else to be dropped, at very low CPU cost.
This means that, even without replacing the kernel, we can replace the kernel, as soon as you catch its first event, which is run before any logic is run.
Even if the kernel did set-up itself a bit, it's nothing more than some internals and potentially some events, but can still short-cicuit those using the right priority on your own.
Of course, this is all theorical, but I have to check the Drupal overrides, but in any mean, it is meant to be used this way.
So yes, even hardcoded, the kernel is pluggable.
Pierre.