or the whiskey lovers in the room. The original kind of mission statement was to transform in Drupal from a first class CMS to a first class REST server with a first class CMS on top of it, which means we need all of this fun stuff, powerful context system, context sensitive layouts, block-centric layouts, plug-in mechanism, and yet no one actually understands what that means. Bottom line, what we're trying to do is convert Drupal from a page-serving tool into a HTTP REST serving tool. And then pages are just a special case of REST. People know what I mean when I say REST.  It's going to be a really brief introduction. This is a good thing. So yeah, that's basically what we've been trying to do is convert Drupal into a tier one REST server so that we can do way more powerful things at the CMS level. The original impetus, this is the way a page is built in Drupal 7. Request comes in, and we go to a page callback. We render this big content area blob or render array depending on what it returns. Then we throw this extra stuff around it called blocks that has nothing to do whatsoever with the page body. And then there's this other stuff that doesn't really fit anywhere, and that's kind of the page, and that's every single page on the site. Everything else we do to make it more flexible than that is a hack. Some of them are incredibly nice hacks, incredibly powerful hacks, but they're a hack around the way the system is built at a fundamental level. And this is great in 2002, but not in 2012. And this is the, you can see it, the kind of logic flow inside Drupal 7. Request comes in, load up a menu item, go through our menu routing system, which gets the page callback, which could get back a render array or a series of Ajax commands. We don't quite mark them separately very well. Then we call the delivery callback, which if it's an Ajax command goes through its own pipeline and then ends up with a print. If it's a render array, which means HTML usually, we go to that, go through a page build process, which then takes this big render array and throws extra crap onto it, including building blocks, which is throwing more stuff onto this big render array. Then we pass that entire thing through an alter form, which means anything can change anywhere without you being able to control it. And then we compile all of that down to a gigantic HTML string and print that. In order to do anything useful besides full pages, something like services module, steps it out and re-implements the entire system itself on top of it and has its own architecture in there and its own output point. And I haven't even gotten to panels. Yuck. This just is not sustainable. This is where we want to end up. Request comes in, pass it through some core routing system and we get back some controller object of some kind. And that renders a page response, which consists of a series of blocks inside it that get that information, get that contextual information about how a page is built, about what the information of the page is, like what node am I on? What user am I on? What is the organic group of that user? What's the language the page is in? All of this information that is really, really relevant that we don't deliver anywhere right now except for the core body of the page. Each of these individual blocks then depends only on this information passed into it, which means if each of these blocks we can uniquely address with the URL, we can fire any block as a sub-request, as an ESI request from Varnish. So we can do partial page caching in Varnish or straight in Drupal. Or we can do an Ajax callback. Any block becomes something you can Ajax replace. This is insanely cool if we can turn around our rendering system and build the page top down instead of inside, outside, alter and stuff. And this is what we've been trying to do, build the infrastructure that makes this possible. Actually implementing this picture is the responsibility of the SCOTCH initiative. They're the last session today in this room. Come back for that too, that's part two. But we've been trying to build a plumbing to enable this. And that is how we ended up with symphony. How do we end up with symphony from that? Well, I'll tell you. Originally we knew we wanted to abstract HTTP request response handling because superglobals are not gonna hack it for what we want to do. It's just not gonna work. And we said, okay, let's not write this ourselves. Someone must have written this already in PHP. We're all about dealing with HTTP. That's what PHP is for. So someone must have written this. Let's just borrow that one piece from somebody. And so we looked at a couple of different options in particular symphony two and Zend. And we ended up going with symphony two for three reasons. One, their library was a little bit more robust than Zend's. Not by a great deal, but it was a little bit nicer. Two, at the time, Zend had a contributor license agreement. So you couldn't actually submit code to Zend framework unless you signed a form saying guy, this claim copyright and patents and all the kind of fun stuff and symphony didn't. And I figured we're going to want to work upstream at some point once we do this. I don't wanna have to deal with that. I don't wanna tell people I have to sign forms and fax them in before they can work on Drupal. That's not gonna fly. And three, as we were having this discussion, several people from the symphony community came in to that discussion and offered to help and engaged with us. And those people are actually here at this conference. One of them is the keynote tomorrow, to be in Pontossier. And that kind of community interaction is something that we felt, and I in particular felt very strongly was more important than the code library itself. We're going to be engaging with this other community to some extent. We want them to be a good community. And so we went with symphony. And so we continued using that library and trying to build this inside out model and okay, how do we do this? And this part is weird and I don't actually know how we do this thing and so on and so forth. And we got kind of frustrated because we kept running into technical problems and process problems and I don't understand it yet problems. And then I started looking at some of the other pieces of symphony that we weren't using yet and said, well, crap. What we're trying to build is symphony, is how symphony's request handling works already. Open source for the win, let's use it. That's basically how we ended up with saying okay, Drupal 8 is going to be based on symphony. Not on the entirety of symphony however. Symphony consists of two pieces. There's the symphony components which are a reusable set of freestanding libraries that can work with each other but can also just live in isolation. And the first one we brought in was the HCTP Foundation library which is requests and responses and stuff like session handling tied into that and that's pretty much it. So it's a way to abstract away from super globals so that you can do more robust handling. And then there's the symphony framework which is a full stack application framework built on top of those components. We're not using the framework. So if you've worked with symphony full stack framework we're not pulling in that entire thing. We're just pulling in six or seven or so of the symphony components, the major ones and building our Drupal framework on top of that. So in particular, I think we may have gotten, did we remove that from the yet catch? Class loader? It's still symphony. Okay, so we're using symphonies class loader for auto loading classes off disk. So who here hates the registry in Drupal 7? It dies at the end of this month. Yeah, so there's a lot of work that's gone into converting over to this. What's that? Can you write it? I did write early versions of the registry. I'm very happy to see it die. HTTP Foundation, which is the request response library. Event Dispatcher, it's basically object oriented hooks and you understand Event Dispatcher. They're dependent to injection container. And most importantly, HTTP kernel and routing. We'll talk about that a little bit here. And so we end up with this hybrid system that the goal at least is it gives us all the benefit of the years of work that has gone into building this solid foundation and symphony components that then we don't have to spend years working on, but then gives us still the flexibility and the freedom to build something uniquely Drupal on top of that, that remains a market leader the way Drupal is today. It frees us to do the parts that are actually cool. And so this is where we end up in terms of the new page request flow. Request comes in, we have this kernel that takes care of routing that request to a controller. Controller, think page callback only OO and fancier and more powerful. That controller returns a response object. And that response object can be an HTML string, it can be an HTML fragment, JSON response, a redirect. It unifies all of that stuff. So you don't need to call location headers in the middle of your code and then call exit and hope that things still work. And that controller can also make a complete sub request which goes through that exact same process. So every block is or can be a separate internal HTTP request or separate request from Varnish or separate request from the browser in Hinclude and it's tortoises all the way down. Does anyone actually get that reference? Okay, I never know who's gonna get that one. So this is where we are pushing towards and it's where we are not at yet.  All you can map on is the path. In Drupal 8, you can map on path. You can map on the MIME type. You can map on the HTTP verb. So we can actually do things with HTTP put if we want to. You can do things with HTTP delete. We can do post. If we actually found a use for it, we could even use HTTP patch. There is in fact a patch command in HTTP, a app that anyone uses it, but we could support it if we want to. So the kernel in particular, I wanna spend a little bit of time on this. It's in there. I've never used it, but it's in there. So kernel, this is the most important part of the flow. An HTTP kernel in symphony and now in Drupal 8 is simply an object that implements this interface. Request goes in, response goes out. That's it. That gives you a lot of flexibility to nest things inside each other without them realizing they're being nested. And that's where you get that ability to do sub requests sanely. That's where you get the ability to break up the page. That's where you get the ability to do HTTP based caching. Symphony comes with a default implementation of this interface that is quite nice. We are using it now. Basic flow of control, request comes in, and a request event fires. Events again, think hook. And then you can mutate that request. Then we have a resolver which says, okay, map that request to the controller that's going to actually do something with it. Controller is just the thing the kernel asks to take care of a request. That gets us back a controller and the parameters for it, which we call and we get back a response. You resolve the controller and the parameters to it. It's technically two operations. Then that gets us back a response, which we can return because that's already wrapped up and taken care of the esoteric weirdness of HTTP. Or if it returns something that's not a response, we get another event that fires that lets us mutate that. So right now, all page callbacks return strings or render arrays rather than response objects. So we have a view listener that takes that and mutates that into a response object. So we did not have to rewrite every page callback in all of Drupal yet. We should eventually, but we haven't needed to yet. If along the way you have an error, you throw an exception and that gets handled and that can give you a response. So you can do much better error handling than we can do now. You can also make a sub-request and run through that entire process again and then merge the requests together. And then anywhere you see request, that's cacheable at the HTTP level. And you can do that symphony ships with on HTTP cache implemented in PHP. Think varnish ported to PHP. And so we can use that as our page caching mechanism and block caching mechanism in a much saner way than we've got now. So this workflow is in core today. We are not fully leveraging it yet. And I say yet because I'm hoping that we can get rid of that yet in the next couple of weeks. So does this sound good? Good because it's not done yet. It's far from done yet. And now we get to the begging part of the session. So here's what we've managed to actually accomplish so far. We've got the request response workflow in place. There's still a few places that we're not leveraging it yet. There's open patches for it. Like Drupal go to is still there. We need to replace that. But for the most part, the request response logic is in place. We have that kernel based workflow. So we have that controller, request object, exception handler and so forth. That's in place at the moment. That's already running in Drupal 8. We have an event dispatcher in place. Event dispatcher does not replace hooks entirely. It replaces the low level bootstrap hooks. It replaces the stuff that's in, it's used for the stuff that's in the kernel flow itself. We're not replacing all hooks, not in Drupal 8. Just the stuff that's along that critical path there. We've got the kernel in place, that's redundant. And we have the symphony dependency injection container. Who here gets confused when I say dependency injection container? Okay. Short version. A dependency injection is use function parameters the way they're supposed to be used rather than calling from a function to a bunch of other things and having hard dependencies. That's really all it is. What's that? No. I'm still confusing, Peter. So if you have a function that calls a function, that calls a function, that calls a function, that calls a global. This function is now dependent on the save of this global. Go to task. Try unit testing that. This is why Drupal has very few unit tests compared to system level tests. If instead you have a function or an object into which in the constructor you pass a bunch of objects and they can just call those rather than instantiating it themselves, then you can pass in fake objects and unit test it. You can pull apart your code and work on it independently. You can have two people working on different parts of the system without breaking each other. So you can actually work on theming without breaking entity load. Which is kind of nice. A dependency injection container is a fancy academic name for an array of objects. Really all it is. That then takes care of, this object requires these five other things to be passed into it. It just takes care of that for you once you've set it up. It sounds a lot scarier than it actually is. And Jess is still wincing. I was actually smirking, but I don't think they're gonna do that. And so we've got a couple of things that are using the injection container now, but not most things. So that's where we are now. We have a lot of really cool shit in core now that we're not really taking advantage of. And if Drupal 8 shipped today, it would work. It would just be horribly over engineered and not accomplish anything really new. Few things here and there, but really nothing really new in earth shattering yet. If we want the really new and earth shattering stuff to be there, here's what we still have to get done and what we need your help to work on. So first of all, we need a new routing system. That is somewhere around two thirds implemented at the moment. This replaces hook menu with a symphony style routing system. I have some slides on that later if you really want. That lets us do things like routing based on MIME type, routing based on HTTP method and so forth. Right now core still doesn't do that. That patches in progress, needs reviewers, needs people to help figure out some of the edge cases there. Our Ajax system is still using anonymous arrays that you kind of hope you can figure out. This needs to be converted to you really using the symphony logic directly, return a response object that has the information on it we need. There is an open issue. I will be putting these slides online. All of these links are live. I have a description in this issue of how this should work. We just need someone who understands Ajax to jump in and make it happen. Content negotiation. Right now we can map based on MIME type but it's a hard coded list of known MIME types. That's really not flexible enough. We want something better than that. We have a start on a new MIME type negotiation library that is based on Apache's mod negotiation. Really powerful algorithm. This is not done. Wammelton has started on it. It's actually a project on GitHub because there's nothing Drupal-centric about it. We need someone who can help carry that forward and really nail that. So they begin to pull that into core and then be able to map on is this JSON-LD, is this our custom Ajax for ah-ha, is this some other type of JSON, is this atom? That kind of information, we only have a very rudimentary form of now we need a full on system for. Entity property API. We want to be able to do real content staging, real Drupal syndicating to Drupal content staging. In order to do that, entities need to get a lot cleaner and a lot more standardized. Work on this is in progress. Fago and Dixon are working, who was in their core conversation yesterday? Okay, all the stuff they're doing is important for Whiskey because that is how we can then take an arbitrary entity and say, okay, serialize it to JSON, ship it across HTTP somewhere, turn it back into a node object and call save. That's where we want to end up. We're not there yet. This needs to finish first. Symphony has a fairly nice session handling system that they modified and upgraded specifically for us to be able to use. It's really nice. We have a patch to switch our session handling to theirs, which helps clean up our bootstrap and hopefully lets us make the bootstrap thinner and help the installer and various other things. That's been sitting for a while now waiting for our reviews. So this is not directly web services, but it is, here's this ugly piece of code that we've got a replacement for, that the code for it is already sitting in core because we pulled in these libraries. HTTP, that's one of the holdups on that patch right now, is that question. But yeah, it's a session swap out. HTTP based caching. Remember I said we had Symphony comes with that varnish NPHP library. We're not using it yet. We need to. There's a patch in progress on that, but it could use reviewers, it could use people who understand HTTP to help with that. Is Mark Sonnenbaum in here? Okay, Mark Sonnenbaum is working on that, but he only has so much time. Block URLs. In order to do this, we need to figure out, okay, what is the unique URL address of a block? Part of this ties into the Scotch initiative, but we need to figure out how we're going to expose that to them so that they can build that layout. Once we have that unique URL for every block, then we get block level caching kind of for free. Things like autocomplete can easily, I have an extra letter in there, easily be ported, yes. Can easily be converted over to the new routing system. That's a fairly straightforward change. Once the new router's in, we just need people to sit down and do it. We don't actually have that many of them. There's the Ajax system and autocomplete, and I'm not sure that we have any others at the moment. Cron has already done. We need to figure out, for the Scotch initiative, for that layout stuff, how we're going to actually glue those two pieces together. And that's a tricky problem. I don't have an answer yet. We need to find one. And then of course, there's this question. We're just ripping routing out of hook menu. Menu links are still gonna exist. Hopefully they turn into entities, but that's a separate process. So what becomes of hook menu, and the stuff that's in hook menu now? I don't actually know. We need people who can dive in there and figure out what makes sense to do with menu links now that they are not joined at the hip with the routing system. So this is stuff I feel has to get done. There's other things that would be really nice if we get done, but could live and contribe if we don't make it in the next three months. Once we have those standard entities, we want to be able to serialize them to JSON-LD. If that lives and contribe, that's okay, but I'd much rather have that work ready to go when Drupal launches. And if we can get part of that in core, great. Lynn Clark is who I think just walked in back there is leading that work at the moment. Outgoing requests. So for everything we've talked about is incoming HTTP requests, serving requests. But a real web server, a real web services system needs to be able to make requests just as easily. We have a patch right now to replace the ugliness that is Drupal HTTP request, which misses a lot of important features with Guzzle, which is another third-party library that's used by a lot of symphony projects that has far more features than Drupal HTTP request that has like of the 11 features we listed off that we wanted it in a library. It has like 10 and a half of them. Only problem is it's about a megabyte in size. So we wouldn't be loading all of that on every page, certainly, but it's got a lot of code. So do we use that? Do we use a different one that's smaller and less capable? How do we handle that? We need to resolve that. Could happen in contribe, but I'd much rather have that in core if we don't need to think about different libraries for that sort of thing. Path alias refactoring. This is mostly a cleanup, but now that we have this more robust request system, we can do a lot to our path alias system to just simplify it, to make it more modular, make it easier to swap out if you're not using it or to swap in an alternate implementation. Cat Bailey is working on that patch now. It could use reviewers. Generators. Basically, that's using routes in symphony to generate URLs by name. So it's roughly equivalent to URL, the URL function, but instead of hand crafting a string of node slash dot five, you generate a route to the machine name node page and a parameter of node five, an associative array. This is great because then you're separating your link from the actual URL. So if you really wanted to move your nodes from node slash to content slash across your entire slight, you could. If we can do it in such a way that we can support fallbacks, you could have natively different node types at different base paths. I'd love to see that. If it doesn't happen, it's not the end of the world. It's just unfortunate, but I would still like to see that happen. Binary stream response. Symphony support stream responses. So instead of iterating over, instead of building up a gigantic file in memory or something and then trying to print that, it can create a response that when fired, rip stuff off disk and sends it.  Very efficient. We're using it in a couple of places now, but even better if our code doesn't need to do an iterate over a file off disk every 1,024 bytes and it's gross. Because there are way faster ways of doing that. There is work that we've been pushing upstream in symphony to simplify that. That I would love to see get into symphony because then we can use it. Again, not the end of the world if it doesn't happen, but it'd be really nice to get done. That dependency injection container, we're only using a little bit right now. Anything we port into it becomes unit testable, becomes lazy loading and doesn't actually cost us anything if we're not using it in a given request. Anything we can move in here improves testing and improves performance. We just need to sit down and convert stuff over to it. There's a lot of those low level hooks, hook URL inbound alter, hook init, hook boot, that really could go away. Because we don't need them anymore because the symphony requests, or the symphony events that are already there accomplish the same goal. So that's a straightforward clean up, remove old crufts and port things over. Forms currently, who here actually understands how forms are processed on submit and Drupal? Okay, not everybody. You realize that? Honestly, no one. Okay. How many people realize that in order to submit a form, we halfway render a page and then process it and bail out halfway through the page with a redirect? Isn't it gross? So there are a couple of ways we can clean this up now. The easiest, and this is something someone can work on today, is when the request is coming in originally in the original request event, check and see if it's a form submission, load the form processed right there, and assuming there's no validation error return right then. We can skip over most of the page that way, much cleaner, much faster. The more we stuff we push into the injection container and the more stuff we pick apart, the more stuff we can do lazily, which means bootstrap gets thinner. Everything we move out of bootstrap to lazy load to use the injection container to not have to do on every page before we get to the actual kernel makes responses faster. And when we're issuing potentially multiple requests from Varnish, that really helps because every request cost gets born multiple times. So anything we can do to make bootstrap thinner is gonna help web services. And anything tagged whiskey or kernel followup, which this link goes to. I think there's somewhere around 30 of those right now. Need someone to work on them. I'd like to see most of those green before December 1st for code freeze. Who wants the help? I'm not seeing enough hands. So what we wanna do is, a lot of the stuff is legitimately complicated. I'm not gonna whitewash that.  So what we need are people, I'd say two per issue at least, who are able to just dive in and commit time for several weeks to make sure that these things happen. So if you are interested in owning one of these issues, I will support you on it. We're having a meeting right after this session during lunch back over in the Coder Lounge in the Westin Building. Come talk to us. We're going to the other building. There's a more room there. Okay, well maybe we'll do it here. Well, we're meeting somewhere right after this to map out who's gonna tackle which piece. How are we going to make sure that these get tackled instead of falling off people's radar? How can we support people in owning these issues and really getting them solved? And again, we need multiple people for each one of these. There is nothing more disheartening as many of you know as putting time in on a patch and then it sits there in the queue waiting for a review for the next four months and by the time someone looks at it, it doesn't apply anymore. So two people at least per issue is what I'm targeting. Think we can do this? We've got three months left. Think we can do this? I hope so. Got a half hour of questions and discussion, microphones right here. Any volunteers, anyone want to say something? Just walk up to the microphone. What about the installer? What about what? Installer. The installer. So there is work going on to, who's actually looked at the code inside the Drupal installer right now? Did you run screaming? I did. So we have the potential with the symphony framework with the dependency injection container and so forth to convert the installer from a one-off hacky script into a micro application of its own. Built on all the same principles as Drupal Core that can install Drupal and do the same thing for the updates.php file and so forth. There's a patch for that right now. Latharian is working on that. Again, like all of these others, could use support, could use someone else to work on that. That's not critical for web services.  So I'm not gonna be focusing about myself but if that's your passion, please don't let me stop you. Talk to Latharian, he's taking point there at the moment. Do we have any Drupal specific modifications to symphony or are we strictly using upstream symphony? We are submitting pull requests to symphony upstream that we can then pull back down. And we have already 10 or so pull requests that have gotten in just from Drupal people that have written stuff. Some of them are fairly minor. The largest one actually symphony natively doesn't actually do route matching on anything but minimal part of the request. We've started to introduce a new part of their routing system to do full request matching, which we're using. That still needs to work upstream in symphony as well. But yeah, the symphony that's in core is vanilla symphony but we have been working upstream in symphony and they've been very receptive to that so far. So any work you do in symphony itself is also benefiting Drupal. Cool. That sounds really cool. How does the anatomy of a module affected by a lot of this object-oriented cool stuff coming into what used to be a mostly procedural system? I expect Drupal 8 to be something of a hybrid. So some hooks are going to turn into listeners which means they're going to be classes which means they lazy load for you and so they're not going to weigh down your request if they're not used. Some hooks are just going to say as they are nothing we're doing is going to affect those like hook node load, I'm not touching that. Page callbacks. Some or all of those are going to turn into methods on objects which like anything else can lazy load. How much of that happens is going to depend a great deal on just how much manpower we can throw at it and what exactly Scotch ends up doing there. So a lot of that is still to be determined. But yes, modules in Drupal 8 I expect to be half OO, half procedural depending on what it is they're doing. So there will certainly be some modules that are just OO which suits me fine personally. Yeah, quick note on JSON-LD. I actually have a proposal available on the Whiskey Group. It's, I think it's a second post right now. There's an implementation of JSON-LD in Drupal 7 contrib, but using the same idea that we're planning to have in Drupal 8. It's not complete, but I'd like to have some feedback and see whether that's the wrong direction or if we should continue in the same direction. Okay, so if you're interested in JSON-LD, you know something about semantic web. Talk to him, talk to Lin Clark. There is a meeting also at six o'clock today in the corner. Talk to him at six o'clock. What do you expect in terms of performance when Drupal 8 comes out? My hope is that on the micro level, certain things will get a bit slower, but on the macro level, the architectural performance and performance we can make will overshadow that. So like processing an event is more expensive currently than firing a hook. There are things we can do to make that faster, but that cost, I expect, will be offset by a typical page request because we can have much more robust caching. We're gonna be rendering this part of the page instead of this part of the page, so it'll be much smaller so it'll be a net win overall. That's my current plan. That's my hope. I have not benchmarked at a micro level yet for that. We're focusing on architectural level performance improvements and micro level benchmarking that we'll do after code freeze because we can still make those changes later. That's kind of the approach at the moment. So in Drupal 7, we have this page callbacks and in Drupal 8, we still have them, but we also have this controller thing. And imagine that the controller thing should be an object, a class or something. And how do you imagine that we will map those old page callbacks to controller objects? Will we group some of them together or how would it work? So a controller in symphony can be any callable. It can be a function, it can be an anonymous function, it can be a method of an object. At the moment, we have it set up so that any function is assumed to be a legacy page callback, so we have to handle it differently. But my hope is that most controllers are methods on classes because that's, I think, the most performant. Depending on how much, again, how much manpower we can throw at it and what scotch ends up needing, that may or may not happen, so we may still have some function-based controllers for legacy reasons for now. Again, I don't know, it's gonna depend on implementation details as we plow through it and resourcing. So could I mention that maybe someday in the future, the node module would have one class with a lot of controller methods, or would you rather split this up in some way or how would you reflect on that? So how will modules look in the future, that's a basic question, or the part of the page call? I believe symphony and most rail-style frameworks, which symphony is not, but it's similar in this regard, have all of the CRUD operations for a given object type or on one class. I don't think that's actually the right approach for Drupal. My guess is we'll end up with do what makes sense in that case. There's nothing stopping you from having a module that provides eight controllers spread across three classes if that makes sense for your use case. So again, that level of implementation detail I don't know yet, I don't think we're going to know until we actually can start writing those and see, oh, so what does this actually look like in practice? It's not going to end up with every module has one huge class followed by its page callbacks, that's not happening. Should I make the next, or I had another question. Okay. Okay, so dependency injection container, as I understand the way that we want to use it is that we have some kind of configuration for an object and so on construction all the stuff the dependencies can go in and the object itself does not need to depend on the container. An object that is being managed through a dependency injection container does not know that it is inside an dependency injection container. That's a good thing. That's how you can just rip it out, stick into a unit test and test it manually. If you look at the current router patch actually, I've got a very good example of that. We've got a number of classes that use a database for dumping route information. They're all pure unit tests because all I need to do is pass in a database connection. So the point is that at this point it's not lazy anymore really because all the dependencies have to be constructed and put into constructor. And so some blog posts on the internet talk about some lazy group dependency resolution but then again you need to know the dependency container because then you have to pull it when you need it. So what is the solution? Do you have something in between that you don't need to the container? So you can still lazy. In some cases you do want to pass the dependency injection container into an object. In that case what you're doing is a service locator and then it can just call that object and get stuff from it as needed. In most cases when you have well-factored code an object is only going to have the dependencies that it's actually gonna use in the majority case. So as an example, yes if you're loading up the database backed cache system then it's going to have to load up the database. But it's gonna use it so it's fine. But if you never invoke the cache system then the cache system never initializes so it never initializes the database. Yeah but if you have something that wants the cache system just in case it needs it and then it doesn't use it and then you have the database already and everything. Then arguably that module needs to do something differently because that's a bad plan. Yeah it's not a perfect setup. It's not nothing ever happens at all unless it's absolutely needed. But it's certainly closer to that than where we are now where we load 100,000 lines of code and use 4,000 of them on every request. So it's certainly better than that. So on the service locator would be not just one big thing for everyone but it would be a facade or something for just an adapter for just one purpose maybe. And then another. Now there's one dependency injection container but just loading that container up initializes nothing in it. When you ask for something out of it it then loads just the things that object depends on. Yeah okay, that's. We can go over that in detail another time. Yeah one more question in the direction of how modules will look in the future. You mentioned that some hooks are going to go away in favor of listeners. Can you explain how exactly that will look code wise? Like how if I'm a module and I wanna have such a listener what do I do? Looks like this. So this is event dispatcher a la symphony. So you created the event dispatcher object. Core does this for you. You have some kind of callable method anonymous function whatever called add listener. So you actually have to register it if not a magic name the way hooks are in the setup of the injection container actually. So I'm gonna wave my hand on that for the moment to not get down into the weeds. But you can see some examples of this in core now if you want. And then you can have a subscriber class which is just a bunch of listeners as separate methods and then you register them this way and call add subscriber. Now when dispatch gets called on that event this is roughly equivalent to module and vocall then that's method gets called. Which means you can actually have methods that share information. So like hooks that could share information without having to rely on globals for example. So. Conceptually you could do it anywhere. What we actually have as of like two weeks ago. The dependency injection container in the setup of that you can register subscribers there. So you effectively have a setup hook for the injection container that is not called on every request but only when necessary and registering things in the container and registering events to fire all happens there. So it's more flexible but you have to manually register things. I think it's a net trade off. The net trade off is a win. So there was this at the very beginning of what later became whiskey. This was very much about butter and the central question was about having a context container to be able to say to hold information across several parts of the page like what's the current node? What's the current organic group? What's the current term, et cetera. And at some point it stopped being the central focus and rather yeah how we handle the HTTP requests and stuff like that. So does this context handling, I mean context as in context country module. Did it get like punted over to scotch or is it considered not an issue anymore because we can do that with the dependency injection controller or something? So most of the stuff that we were trying to build so a bit of history. Two and a half years ago, I started babbling about a thing called Butler which eventually got renamed to whiskey when it became an official initiative. Yes, that was a bad pun on my part, very deliberate. So that Butler whiskey effectively the same thing. The context part of that, we were working for a while on a context API for core. Most of what that would have covered is now either handled by the request object that we inherited from symphony or by the dependency injection container which we inherited from symphony or is handled by the way sub requests end up working and is scotch's problem. So that concept of centralizing that and not having all these crazy global functions is still there. It's just not one God object anymore. It's handled in logical separate places but the underlying concept is still sound. Sorry, then additional question. Does it mean that in the list of still to do or would be nice to have things, is there a task for converting current core code to move what would belong in there to actually get to a standard centralized location that country can then also use and set up standards for that or using that or? So it's not context in the sense of context API of a context module in Drupal 6, Drupal 7 which is a gigantic global array. The idea is the word global should be expunged from our vocabulary. So there is no massive central registry of the current state of the universe. Rather there is the request and that is all you care about and it's responsibility of the caller to that block to provide in the URL the contextual information you need. So yeah, there's no global registry of knowledge because there shouldn't be. Is that, I'm not sure if that's answering your question. Okay, so yeah, that original context API approach turned out to not actually be a good idea. The user and the current theme and everything will part of that be end up in the dependency injection container or will it be in the request object or where will we put that stuff? We probably need an issue to decide where some of these things go. Because if it's in the injection container then we are no longer, this container can only be used for this request and otherwise we need to rebuild it. And so where does it go? Well the injection container soon as another patch lands will get compiled. So it'll be fairly fast and fairly stable. I expect current user will probably end up on the request object, my guess. Current theme, I'm not actually sure. That's probably get added to the list. If that's something you're interested in, talk to me, let's put up an issue for that and we can start working on it. Yeah, some of this stuff that's currently global we're just not quite sure where it's gonna fit yet. We're gonna try and get as much stuff as we can into somewhere logical. We're not gonna get all of it. So during the request, the dependency that injection container gets a lot of objects inside and piles up that pile up. And so this is some kind of state but if you would have two requests could you reuse the same dependency injection container because it's not kind of dirty? Kat, you wanna take that one? That's what's combining. Microphone, microphone. Okay. So there's a patch in place to compile the container which means as long as something hasn't happened like a new module has been enabled you're gonna be reusing the same container and it's all gonna be compiled to disk. So. And like serialize it. Well, cause at the moment it's the way it works. It's being like built on every request. So yeah, no eventually it's just gonna be like it's just gonna be one big class that knows exactly where all the classes are. The objects that are managed by the injection container those at the end of our quest those expire and get garbage collected just like they do now. Things like the database connection. You open it when you start using it and it closes when PHP shuts down. That part doesn't change. Yeah, the idea was that if these objects contain some request specific information some module just puts the user ID, the current user ID into one of these objects that are instantiated for the dependency injection container. Okay, what you're talking about is request scoping. Symphony actually has a mechanism for that. So you can tag a given item in the injection container as depending on the request scope. So when a new request, a new sub request is fired Symphony will hold on to that object, create a new one that depends on the new request and then when you exit that request scope throw that one away and go back to the old one and it just takes care of that for us. That's another one of the nice things about its container. An earlier question. Also you mentioned in the Butler, the original Butler presentation in Chicago about including a unified plugin system as part of Butler. Can you comment on where that stands? Is that part of another initiative or? That got forked off to the Scotch initiative back in February. That landed, that's in Cornel. It still needs some cleanup and it still needs people to help implement it in the 15,000 places that it's useful. We're not gonna get to all of them but if you're interested in that system talk to Chris Van Der Water, he'll be here in the last session today. He needs hands just as much as I do. Anyone else? Who is interested in helping and knows that they are going to have the bandwidth to be able to do so in the next couple of months? See a couple of fans. Okay. Second question in the hard part. I admit, the second question in the hard part it's kind of hard for me to measure my own bandwidth at times. So I fully appreciate that but we need to make sure we can build a team that can just tackle these issues and drive this home because I really would hate to end up with a Drupal 8 that is two systems sitting next to each other both of which are half complete rather than one system that actually does everything we want it to do. As a Drupal 8 is chippable today, all the tests pass. That doesn't mean I like where it stands right now and we want to finish this process just to make sense we can. Hi, so just sort of a plug. So some of you that might be concerned about how much bandwidth you're gonna have over the next couple of months. Some of you maybe are full-time employed with some employer. That employer might be very, might have a business that depends on things like content staging being possible, native apps on mobile devices being possible. So go back and talk to your employer and see if you can maybe get some time to work on this. Yeah, if you want request handling, if you want web services to work in Drupal 8 rather than be a hack layer you can sell that to your boss. If you want the core system to be able to support one good layout system instead of a crappy layout system in core and a couple in contrib that don't talk to each other then we need to get this work done. You can sell that to your boss as well. If you need help with the sales pitch, talk to Alex, talk to me, talk to Jess. What? No, don't talk to Jess. Okay, don't talk to Jess. But there are people who can help with the sales pitch too if you need to make it if you're interested. You, which is going about to change I guess. Currently we have in this one hook we give information about the route and also about meter information to put this in a menu somewhere to make a breadcrumb and to make tubs. And this is dirty but it's kind of convenient and it guarantees that for all these admin pages you don't forget to put the breadcrumb or the tubs but you just get it all for free and you just use one place where you put all this stuff and if you change it you're only changing this one place and if we split this up then will it make it more difficult to keep this all synchronized? Isn't it for some use cases nice to still have this hook menu with both things together? That's item 10 on the list. What do we do with menu links now? I don't know. Yeah, it's beyond many links, so microphone.  So I think we should split this up. A lot of the structure of hook menu was essentially mimicking what Drupal 5 did in order not to... Which means Drupal 4.5 because it didn't change. Well right, or not 4.5 but maybe 4.6 anyway, whatever. But in order not to make people's heads explode as they converted from 5 to 6 a lot of these behaviors were retained even though they were very hacky. I think having the names callbacks will help because then you can say my admin pages have these names and you can go then and change everything else about them all you have to do is specify the names the same with links. I mean Drupal 7 already uses menu links a lot less for actual user navigation. Like you generally don't see that large pile of links in the left block that you used to see. So again, I think what we have now is a convenience system where we know that a path exists and we automatically register it as a link. I think making that explicit is a little bit more work but I think it would be a lot cleaner. And yeah, I think that overloading that one hook with all that stuff is just led to more problems. Yeah, I would agree. How you see this initiative would clean up the overly implementation, the iframes and stuff or is it a question for a lay out group? Overlay. Yeah, overlay. My hope is that one of the things we can do with a stronger web services underpinning is overlay becomes just another type of rest request. That means we can clean up that process and have an actual client side app in JavaScript that is overlay that makes real requests against the server rather than the kind of tricky backdoor-type things it does now that are kind of gross. We need to get the new router in place first before we can do that. We need to get the revised AJAX system in place to take full advantage of it and then we can start cleaning up overlay. I'm not really focused on that one. I'd love it if someone did after we get to the point where we can do so. So I'm hoping we can get to there but it's not something I'm looking at directly. Okay, we're just about at time. If you want to join us for a strategy meeting, I guess let's just meet up at the front of the room here and then we can figure out where we're gonna go. Otherwise, enjoy lunch and hopefully still see you in the issue hues because as I said, there is a legitimate risk that we end up with a half-written system that no one's gonna like. I don't want to end up there. I need help to get to that point. These slides will be up on the internet later today. I will tweet it. Just follow me at crel and includes lots of links to places to go help. I don't know if you have anything to add to this key or parallel dash program. And any of those types of things that you don't want to jump on, I got to mention we also have we've been asking people to dash with C in the other week. New New York time, so that's what I'm trying to do. And I think that's trying to get to the entire work day. Thank you.


Abstract light propagates in various ways depending on its environment, such as uniform media, surfaces or interfaces, and photonic crystals. These phenomena are ubiquitous in everyday life and have been used to create advanced optics technologies. In this study, researchers discovered that a topological photonic crystal exhibits unique electromagnetic, EM, transport properties resulting from the direct frequency dispersion and multi-component spinor eigenmodes. By measuring precisely the local pointing vectors in microstrips of honeycomb structures, they were able to show that a chiral wavelet induces a global EM transportation that travels in the opposite direction to the source, which is closely linked to the topological bandgap specified by a negative Dirac mass. This novel-hygens-Frenel phenomenon is similar to the negative refraction of EM-plane waves associated with upwardly convex dispersions of photonic crystals, and these findings could lead to new advances in photonic innovations. This article was authored by Xingxiong Wang, Ji Weiguo, Wang Song, and others. We are article.tv, links in the description below.


Good morning. So, welcome to today's lecture. We were discussing sensitivity enhancement and in previous lectures we have seen that like NOE is a method to enhance the sensitivity. NOE if you remember we were if two spins are coupled, we were perturbing one spin and because of this perturbation the signal for other spin was getting enhanced. So, we will continue with that and today we will continue with selective polarization inversion that also we discussed in the last class. So, here what we discussed that if two spins are coupled say spin is proton and carbon-13. So, energy level for these two spins are something like this big delta is for say proton and the small delta is maybe for carbon-13. So, two signal A1 and A2 for proton, X1 and X2 for carbon. So, what we have seen that this is insensitive nuclei which is coupled with a sensitive nuclei and what we want to increase the signal of insensitive nuclei which is 13C. So, we had seen that if we somehow perturb or saturate or transfer the polarization of say one of the transition from the more sensitive nuclei which is H by applying a selective pulse. So, selective pulse can be say 180 degree pulse then population of these gets inverted and because of this population inversion the essentially signal for X gets enhanced. So, if you population invert of A1 the X that was signal which was earlier very small say something like this now it becomes quite large, but one thing happens that the sign actually it changes. So, enhancement also we have seen that it is given by a factor which is gamma A divided by gamma X. Gamma A is a gyromagnetic ratio of proton and gamma X is gyromagnetic ratio of the X nuclei. So, suppose we are doing it for carbon proton. Now, gamma for proton is four times more than the carbon 13 therefore signal enhancement that we get in X is four times and this is huge or substantial enhancement in the intensity of X transition. So, that is what we had seen. So, let us take a real example and we will see how much enhancement we are getting for. So, here we are taking chloroform chloroform is CH 13 C and here we have CL CL and CL. So, we have two spin system proton is sensitive nuclei and carbon 13 is insensitive nuclei. We are say recording a spectrum for carbon 13 on any reasonable spectrometer say 400 megahertz. Now, because both of these are coupled so carbon 13 spectrum for X which is 13 C will be coming to here X1 and X2 these are the two transition for carbon 13. Since they are coupled so you are getting splitting and this splitting you remember will be J of CH which is generally 140 or 125 hertz. Now, if you decouple it so you get signal enhancement because of now both spins will merge and give you enhanced signal. But here selective polarization transfer if you saturate the signal coming from like proton. So, if you remember proton will be also splitted into two which we were calling in the previous slide A1 and A2. So, say we perturb A1 with a selective pulse selective 180 degree pulse. Now, signal for 13 C will be enhanced and you look at the enhancement factor here for like X2 it is quite a bit of enhanced and for X1 also it is enhanced, but for X2 it is quite a bit and this enhancement is generally given by gamma A divided by gamma X. So, generally 4 times enhancement that is what we get for say X2 spin or maybe 5 times actually. So, 1 plus 4 that is 5 times enhancement we are getting and for this one we will get 1 minus gamma A divided by gamma X. So, that is 3. So, 3 and 5 we are getting enhancement average is 4. So, 4 times enhancement we are getting for 13 C signal and if we perturb A2 spin so this will be giving us 5 times enhancement and 3 times. So, this is plus 5 minus 3. So, essentially 4 times enhancement we get for chloroform. This is fantastic. So, that is what we saw in the case 4 time enhancement for carbon 13 and if we like take it something like say nitrogen 15. So, nitrogen 15 we get 10 time enhancement and that we can see because the gamma for nitrogen is actually 10 times less than proton. So, that is what happens. So, for if we take it say gamma for proton and gamma for nitrogen and 15 that is 10 times. So, for nitrogen we get 10 times enhancement and this is very very substantial. So, that is what we do in SPI selective population inversion or this is also called selective polarization transfer. In both case we are getting quite a bit of enhancement, but the problem is that we have to select a transition and apply a transition selective pulse for inverting the population of either A1 and A2. So, for this case now we need to get it a selective population inversion which is many times in multiplate it becomes difficult. We get all those selective enhancement, but selecting a 180 degree pulse which is very very specific to particular transition is difficult and when there is a crowded spectrum then selecting a transition which can be inverted is very difficult and therefore we discussed and another experiment which is called inept. So, insensitive nuclei enhancement by polarization transfer concept is same we are transferring the polarization from A spin to X spin, but now we are we do not have to be selective in inversion. So, we explain this experiment we start with a 90 degree pulse on A spin which is sensitive nuclei like proton and that selectively brings the magnetization to XY plane then simultaneously pulse is applied on A spin and X spin and in vector diagram we saw that during the stow period they start moving apart and then you apply then they turn it back in this direction and again if you apply 180 degree pulse on Y there are actually direction changes and during this stow period they come in minus Y direction. So, you apply and bring A spin to Z direction of so this will be say IZ and then you apply a 90 degree X pulse on carbon 30 spin. So, that becomes say SY. So, that can be detected. So, now to circumvent the issue related selective inversion this inept can works and they that if you look at all here we are using is hard pulse. So, we are not now transition selective pulse and we achieve essentially transferring the polarization from high gamma nuclei which is proton to low gamma nuclei which is carbon. So, now magnetization is starting from here comes here and we can detect it S nuclei or X nuclei which is 13 C and it works in similar manner it selectively transfer the polarization from proton to carbon. So, we get an enhancement of four factor that we are saying one important parameter here was tau and tau is a time delay where we can select 1 by 4 J. So, this depends upon the coupling between these two spins carbon 13 and proton. Say typically for carbon 13 proton J value is 125 or 140 hertz, 120 to 140 hertz we can write and J H N. So, this is 1 H 13 C and this is 1 N 15 it is actually 90 hertz. So, that means this tau period if you are transferring the polarization from proton to nitrogen you have to keep here tau around 2.7 millisecond for N H transfer and for carbon transfer it is less than that. So, total tau period here should be for nitrogen transfer 5.4 millisecond and for carbon it will be 1 by 2 into J which is say 140 hertz that will comes around total is 1.5 millisecond. So, inept has some disadvantage, disadvantage that we had that actually it gives us relative like incorrect relative intensity because of different spins and multiplates that we have seen and here one important parameter that we discuss is heteronuclear J coupling. So, if you are you have to select that tau times which is suited to 1 by 4 J. Now, then if the J coupling is quite a strong we have enough time if J coupling is weak then we have different time. So, we have to tune our tau and that is one of the demerit of this inept. The second problem is in case of multiplicity. So, if multiplicity comes then how the spectrum is going to be that is difficult. So, three problem the relative intensity and it depends upon heteronuclear J coupling and multiplicity of spins can cause the intensity anomaly of the spectrum that we achieved in inept. Now, here one can see an example if you have a spins which is say AX, A2X and A3X here inversion is going to be like this. So, X3, X2 and X1 intensity anomaly and some will be positive and negative signal if we record an inept signal. So, we need to know which is coming from which one and this is going to be difficult because negative and positive signal both we are getting in same spectrum. To circumvent that actually one can do a trick in inept and what we can do we can add another say spin a consequence. Inept sequence with this regard of multi plate distortion one can design an experiment which is called refocus inept. Refocus inept means we are adding an extra spin a consequence to the classical inept sequence. So, this additional spin a consequence is identical to the first one and it is added after the last 90 degree pulse and this helps us in refocusing the positive negative signal component. So, what actually it is if you look at here like inept we are starting from a 90 degree then we are waiting for a time tau which is 1 by 4 J. Now, we are simultaneously applying 180 degree pulse on A spin and X spin. We are waiting for again tau and then we are applying a 90 degree Y pulse on say proton followed by a 90 degree X pulse on carbon. So, A spin and X spin. Here we saw that we are getting a positive and negative signal. So, then we are saying let us do an spin echo added. So, that means spin echo is tau we are same tau here we are putting then applying again simultaneously 180 degree pulse on both spin and then we are waiting for tau. So, that actually changes the phase of all three's transition and then it becomes positive. So, here we can see we are getting negative positive negative, but if we do refocusing inept we are getting actually positive positive and positive that is what is the beauty of refocusing inept all signal becomes positive and extra thing we are doing here is applying an spin echo. So, if you remember spin echo is like a 90 tau 180 on both spin tau that refocus all the signal and gives us the positive signal. So, in vector diagram let us try to understand what is happening here. So, we are starting from say Z direction for A spin. We applied a 90 degree X pulse. So, if you remember last time we had drawn this schematic Z, X and Y. So, we started with Z direction of A spin we applied an X pulse. So, that means it went to minus Y direction. Now, here we are waiting for tau period. So, spin starts defaging like this we applied 180 degree pulse on X. So, it inverse the direction then we applied another 180 degree pulse on X. So, that changes the direction now we are waiting for tau. So, they come together and then we apply a 90 degree pulse on Y. So, now it goes to Z direction and here the magnetization on C13 we applied. So, this comes to Y direction and now we we detected that Y that was like this. So, now we are waiting for tau period. So, these spins again starts to move like this. They defage like this we applied simultaneously 180 degree pulse they invert and then we applied actually another tau period. So, they again come closer. So, they are now perfectly aligned in the detector plane and we are detecting it and because of this direction all 3 become now positive. That is what we achieved by adding the extra spin echo sequence after in a all signal become positive. Good. So, let us look at the summary of all those. So, what we are saying now this is our molecule where we are detecting the nitrogen signal for this molecule. So, nitrogen is one of the insensitive nuclei as you know it is gamma is 10 times less than proton. So, if we directly detect nitrogen we are getting very less signal and this is say J is 90 hertz. So, it will be separated by 90 hertz. Then we can enhance the signal by NOE and we can enhance by this NOE signal we can get it. If we do selective polarization transfer the same signal of these 2 will be enhanced for one for this and one for this. If we put up the signal for proton we are getting enhancement into transition of nitrogen one will be positive another will be negative. If we do inept we get this signal and if we do refocus inept both signal will be now positive and that is what we have here. So, by doing selective polarization transfer and inept we are getting certainly enhanced signal and that enhancement is substantial. So, that is what we are getting. So, here is just normal signal here selective polarization transfer because of inept and because of refocus inept all positive signal and if you compare from here to here we are getting substantially enhanced signal. So, that is what is all about polarization transfer in inept signal. Now, I will come to another important concept of polarization transfer is something called Hartmann-Hahn matching condition. So, qualitatively I will explain it you today and then in the next class we will look at more details of what actually Hartmann-Hahn matching condition is. Now, all the time we want to enhance the signal of X nuclei which is low from the more signal which is proton. So, proton has say higher signal and carbon has lower signal that is what we have say gamma of proton is more gamma of 13C is less and that is actually this is 4 times less. So, we want to enhance the signal for 13C how to do that. Now, even on the same as spectrometer that we recorded, so if B0 is same the signal for proton is going to be 4 times higher than the carbon. So, we learned the trick of inept and refocused inept to start with polarization transfer then inept and refocused inept we enhance the signal of 13C. But still we were not getting rid of say B0, B0 effect is there. Now, suppose we do some experiment something like this if the say energy level of proton is like this. So, this is say for proton and energy level for carbon is like this 13C. Now, if we want to transfer this polarization from here to here we can we do some experiment. So, energy for proton is like this and carbon is like this can we do some trick where we can match the energy level of both of these somehow. If you match it the polarization transfer from more abundant nuclei will happen to the less abundant nuclei and probably we can enhance the signal. So, that means we have to match the energy gap between carbon 13 and proton to transfer this signal. How to do that? That is next set of experiment which we can say that we bring in the same environment by doing some trick by doing some locking or you can like say some condition we apply where we start matching the energy gap between these two and that is called either you put them in rotating frame of reference or we can do something called we can match them by Hartman-Heyen matching condition. If you do that the polarization from H nuclei can be increased and that is actually called spin locking or Hartman-Heyen matching condition. So, let us see what actually we have to do and that mostly use this Hartman-Heyen matching condition is the crocs in the solid state NMR. So, here say proton signal and this is for carbon. Now, we want to see this is for 13c and this is for proton we want to match this condition. So, if we say here is omega H and here is omega 13c and if we want to match this condition we do something so that we bring them in a same plane or XY plane and lock them there by applying some pulse and during that probably the with a something called zero quantum flip flop the polarization will transfer from more abundant nuclei to the less abundant nuclei which is 13c. If you do that magnetization will transfer. So, this is called Hartman-Heyen matching condition in solid state how it is done if you say omega H and in solid if you if you know little bit we spin the sample with some frequency omega R with omega 13c if we match this condition then polarization from H spin transfer to X spin H spin to X spin which is 13c and signal can be enhanced. Same concept is used in liquid state where you bring them in XY plane and you lock them applying a weak RF pulse that briefly I mentioned to you in ROG. If you lock them in XY plane the magnetization from H spin will transfer to the X spin and that is called actually spin lock spin lock. So, locking spins in a particular direction for some time and then magnetization will transfer it says like a simple analogy you can take. So, there are two class of people one class is proton and one class is 13c they are not talking to each other but these guys has more energy than the 13c. If you lock them in a room for some time after talking to each other some energy level will be transferred from the more energy guys to less energy guys and that is how you can enhance the energy of the low energy people. So, that is called polarization transfer. So, essentially what we have to do by applying this weak RF pulse what essentially we are doing is matching this condition where we are putting gamma A into B1A is equal to gamma X into B1X. So, now this is not happening in the Ziemann term like if you remember Ziemann is B0 field. So, B0 is main magnetic field. So, earlier if you have seen gamma A B0 is not equal to gamma X B0 and that is how transfer is not happening. So, we are changing from here to here where by applying a weak RF pulse we are trying to match the condition where gamma A which is for proton and gamma X will match. So, now we are applying a weak RF pulse on proton and carbon and we try to match this condition this is called Hartmann-Hahn matching condition. Gamma of say 1H B1 gamma of 13C and B1 on 13C. So, gamma on B1 on proton. So, that means we are applying 2 B1 field 1 on proton 1 on carbon and by matching this condition we can transfer the polarization from proton to carbon. So, that means we have to apply a RF pulse on proton and an RF pulse on carbon which actually equalizes this or which matches this condition then polarization from H-spin will transfer to X-spin and this matching condition is called Hartmann-Hahn condition. So, this is Hartmann-Hahn condition. So, this condition is at the heart of many of the like Rozy experiment or Toxy experiment where bring the magnetization in XY plane and we lock them for some time by applying an RF pulse on H-spin and X-spin and this is also in the heart of all the polarization transfer dipolar based polarization transfer that happens in solid state where we enhance the signal of X-spin by transferring the polarization from H-spin in solids and we detect on X-spin because in solid we generally detect on X-spin because of the lines are sharp for X-spin. So, this trick we will discuss little more quantitatively in the next class where we learn how to do this transfer basically I mentioned to you we are going to match this condition in selective polarization transfer or by spin locking and matching the Hartmann-Hahn condition. So, we will continue from there and we discuss something called 1D Rozy experiment and 1D Toxic experiment for long transfer from proton spin to coupled X-spin. So, I will stop it here if you have any question please write to us and don't hesitate to ask we will try to respond everything. Thank you very much.


This is stock number 9J386A. We are here at Summit Automotive in Fond du Lac, Wisconsin. You're new and used SUV headquarters. Today we are checking out this super clean 2016 Dodge Journey SXT. This vehicle has the 3.6 liter V6 Pentastar motor and from this HD video you will be able to tell that for the age and miles on the vehicle. It is in really nice shape. We shoot all of our videos in 1080p 60 frames per second. So if you have HD capabilities on your computer tablet or smartphone device turn them on right now because it's like you're right here looking at the vehicle with me and definitely your best way to see the vehicle before seeing it in person. If you want to check out more pictures of this vehicle you can go to our website, which is in the upper right hand part of the screen. Click that to check that out. It has the painted 17-inch alloy rims, Firestone Destination 22565R17 tires with about I'd say 60 to 70% of the tread left. Four-wheel disc brakes on this vehicle. I didn't see any dents or dings on that front fender. The headlight lenses are nice and clear. It has the factory fog lights. No major dents, dings or cracks on the front bumper. Passenger side fender is in excellent shape as well and the passenger side rim. I didn't see any scuffs or scrapes. The brakes look pretty new on this vehicle. I would imagine we might have did those in our safety inspection. And as you go down this side of the vehicle you can see just how clean the body is, how reflective and mirror-like that paint is. We take these HD videos so if you're far away or even if you're close by and just can't make the trip down but you're still interested in purchasing the vehicle, you can still see the vehicle, hear the vehicle. And have confidence in what you're looking at before you even get here. Down this side. Didn't see any dents or dings. And we even offer a summit fast-pass option on our website where you can apply for financing. Get pre-approved. Check out your payments and even appraise your trade right on our website. Click the upper right hand part of the screen for that. And back tires have just as much tread as the front tires. Four-wheel disc brakes on here. And that fast-pass is really the best way if you're in a time crunch to get the deal going and make this vehicle yours. Rear gates in really nice shape. This is a manual lift gate. Back storage area is very clean. You get the third-row seats that do go down nice and flat. And up like so. You can see the rear shocks are doing a nice job holding up that gate. Shuts nice and solidly. And as you go down this side, it does have the dual rear exhaust part of the V6 package. And as you go down the driver's side, just as clean as that passenger side. No major dents or dings on the rear quarter. And for full disclosure, this back rim is in excellent shape as well. Down the rest of the side of the vehicle, very, very clean. It does have the enter-and-go system. So you just have to have the key fob in your pocket and put your hand in. It'll unlock as the heated power mirrors. There's that enter-and-go button. And as you look inside the vehicle here, the SXT package gives you the black cloth interior. There are no rips. There are no tears on the seats.  And as we hop inside the vehicle here, you can see that this one has 69,401 miles. Instrument cluster is very nice and clean. Steering wheel is in nice shape. No major scuffs or scrapes on that. Cruise controls on the right and information center controls on the left. You do get an outside temperature display and digital speedometer on that instrument cluster. This one has the touchscreen radio, AM-FM, and Sirius XM radio capabilities on this vehicle.  Here's the key fob for the enter-and-go system. Passenger side-format and seat are in excellent condition as well. It does have in-seat storage and the headliner is in excellent shape as well. You get your map lights up there. Dash is in nice clean condition. And we'll take a quick look at the back seats and then check out under the hood. The like about the journeys is these doors open up a full 90 degrees, so it makes it really easy to get inside and load stuff. Second row bench seating, no rips or tears on the seats back here. It does have the latch child safety system for your child car seats and third row seats are in nice shape as well. No rips or tears back there. Smells very clean inside this journey. I don't think it's ever been smoked in and those seats do adjust forward and back and you get in-floor storage back here as well.  Very clean inside out. I would personally like to thank you for checking out the video today and hopefully from this HD video. You will have been able to tell just how clean this journey is all the way around inside and out. Under the hood, we have the 3.6 liter Pentastar V6 motor. It's been on Ward's top 10 engine list several times for just fuel efficiency, overall quality and reliability. Engine base very clean runs very smooth. This journey has been fully safety to end inspected by our service shop has a fresh oil and filter change. All the fluids have been checked and topped off and this vehicle is 100% ready to go. To see more pictures of this vehicle and one of our other 450 new and used cars, trucks, SUVs, minivans, Wranglers, journeys, you name what we got it. Go to our website www.summitauto.com, full pictures and descriptions of every single vehicle from two locations all at summitauto.com. And if you'd like to check out more HD videos, you can go to youtube.com slash summit auto. Remember to like, subscribe and share on this video and all the videos that you see there. In fact, in a second you will see a link to subscribe to our YouTube channel on your left if you haven't already saw it on the right, bottom right there. On the right hand side, you'll link to more used inventory videos like this one if you haven't been to our website on the bottom link to this vehicle on our website. So click all those, check us out and we really look forward to helping you with this super clean 2016 Dodge Journey SXT front wheel drive. Thanks again.