 Okay, I guess I'm starting. So this is kind of an extended update and discussion on where we're going with entity API in Drupal 7. I basically signed up to do this because I thought catch was coming. I could broke them into work and do it with me, but happily Fago is here. So he put together some slides and this is gonna kind of extend from what Greg talked about yesterday in terms of the core initiatives. And basically we've been talking since, I don't know when, San Francisco. San Francisco, yeah. About even long before that, if you look at Drupal core APIs, you compare node module, comment module, user module, you start to cry because you see that none of them call into the same code in the same order. Drupal 7 is somewhat better in terms of having at least a little more consistency of which hooks are called. But if you look at the Drupal 7 code, you'll see that we have a comment hook, we have a field hook, we have a entity generic hook. So we basically have every hook repeated at least three times with different variants in part to support all kinds of legacy code that expects a certain naming. So moving forward, we want to really unify these and this is really about solving a lot of the technical debt that's still present in Drupal 7. So yeah, clearly Drupal 7, a lot of changes with the field API went in sort of the last, relatively last minute. Things like making all entities able to have fields on them was relatively late in the development cycle. And so there's a lot of implications of that, that change and just bringing a better developer experience by having consistent API so that if you wanna load or save any kind of entity, you don't have to think hard about which parameters to pass in or which kind of data you need to use that it's gonna be consistent throughout every entity type. Both the core types and custom types. So the idea here is that entities really become our generic framework for handling data. People are starting to use them this way in Drupal 7. I just heard that, for example, voting API is considering making the votes on a node entities. Now this, initially I thought, wow, that's crazy, but if you consider that at least in Drupal 7 that really an entity is just a wrapper around saving data to one table, well this is exactly what voting API is already doing. It's just every time you report a vote, we insert a row into the table. So let's just think about using entities as our basic storage framework for everything. So we'll have a consistent API. We'll use this consistently every time we wanna store data somewhere. Who is, I guess Damian was saying, he wants all developers to forget about SQL. So this is kind of, even regardless of what we think about the storage backend, this moves us in the direction of forgetting about SQL, yes? So will you make some of the other things in Drupal entities like blocks, for instance? Good question, is it blocked? You don't have to answer that, it's just a bit difficult. Yeah, I really think. I actually said no when I was raised when I was talking about making blocks an entity. And they said no. They said no. They said no, there was other problems, issues with doing that. Okay. For seven or for eight? All right. I guess blocks are kind of special because things like a view can up in a block and they're really things for putting on pages and so maybe they are different from entities. Yeah. There's an issue to make custom blocks. Yeah, that's what I'm saying. So custom blocks probably should be. Yeah, custom blocks probably should be entities because you think about, okay, there's a box table and it has a list of blocks and each block is, each of those is basically static. Yeah, they have little pieces of content. Little pieces of data, yeah. So, but yes, blocks are general, maybe not. Yeah, I think there really is a difference about where blocks is concept for building your site and as a display container and the custom block you want to. Right, so the custom block. Sure, yes. So in Drupal 7, there's already some amount of pluggable storage for fields and I think we'll talk more that we want to remove any any conception of field API as a separate API that fields are the way that you add more data to entities. Therefore, if we have a unified way of storing data, entity data, then all the field storage is underneath that entity system. Again, this integrates well with what Damian talked about independently if you saw his discussion and since you can make the storage pluggable, very naturally you can if you want store entities as a whole in any kind of either local or remote data store. I think neither of us is convinced that you need to be able to store parts of entities in different locations. So we would really only see entire entities stored locally, stored remotely that should be supported. So in talking sort of about our general roadmap and how we're gonna get there, we can't do it all at once, obviously. So the first step and we have sort of rough outlines of how this code would already look from San Francisco and Fago has already actually implemented versions of this for Drupal 7 and his entity module. But basically taking that kind of code and defining an API, so where you do all the basic create, load, save, delete operations for an entity and start out with some kind of test entity, maybe actual test cases, like simple test. So that we at least have confidence that these basic functions work and some kind of toy entity can be loaded and saved. And that's the easy part, right? Now, we can basically already have that code from Drupal 7, from the entity module, at least a working version. We can argue about some of the details of how the API should look, how we want to use OO, especially because it's PHP 5.3. There's some interesting changes in how you can use, for example, class methods in PHP 5.3 versus 5.2, means we might re-factor some of the existing code. But the interesting part comes when we start porting core empty, so the idea is we would basically set up a parallel system, so it worked for a custom entity and then we would start porting core entities one by one to this new API. And as we do this, we would probably want to do performance testing for each core entity we're converting. Let's check and see if the performance gets better, hopefully, if it gets significantly worse then we have a problem and we need to revisit what we're doing. That clearly needs to be an ongoing part of this cycle. Our hope is that actually performance will get better because as I said before, you basically have, you're evoking every hook roughly three times if you look at the load and save, especially the save operations, for example, also load operations. These hooks are invoked extra times and we're going to eliminate a lot of that duplicated. Hook invocations were also going to be, as we go along, eliminating essentially duplicated code. So we'll essentially be able to remove large swaths of the common module, user module, node module, all the stuff that deals with loading, saving, maybe even viewing, those entities will get removed in favor of this more unified version. That's what I was just going to ask you because viewing was included in this master plan. So Fago's going to talk more about some of the details, but yeah, I think at least you provide some kind of viewing mechanism that's generic for entities, maybe that nodes are special and need their own version of viewing. But that means that if I define an entity, then maybe I don't have to define the viewing. Exactly, yeah, that's the deal, yeah. Right, so it would make it much easier for people to define sort of new entities as sort of content and maybe you don't have to abuse the node for every kind of data storage. So we'll come back to some questions about revisions. As we start to get in, so the first example might be common module or something an entity without revisions, and then it gets even more interesting as we start converting an entity type with revisions, like the node module. And once all the core entities are converted, basically at that point we can start refactoring the field storage functions. So right now we have all these field attach functions and things like that that are in the various load and save hooks. And so we would refactor those and move that, the code relevant there into the entity, basically storage controllers. So there would no longer be a separate way to load and save fields that's distinct from the way that you load and save an entity. So status. So basically Fago and Catch have actually started on some of this. The first step is, which looks like we need to re-roll, patch, move entity API into a module, and really this is just moving code around in core. So a lot of the entity API stuff in Drupal 7 ended up in system module just because that's the dumping ground for new code. So as a first step to sort of having a clean place to work on this kind of API that we move, move all that code, that's really just moving things around. We should be able to get that in pretty soon. And then there's a work in progress, not yet, you know, ready to review or are you certainly not ready to commit? It's basically just a port of the stuff of the entity API module in Drupal 7 to Drupal 8 and just a start of refactoring that to the version that we actually want to have later on. So it's work in bogus, but it already basically works, but it's, yeah, needs work. So, you know, at least we do have an initial start and once this first one is done, then really the basic CRUD operations, I mean, that's where we're defining the API and that's where we will need to make some of the architectural decisions about how we use OO, how we break up the code, and other things like that that I think would be interesting. So one of the questions, if you remember from Chicago, we discussed, you know, should we have an API that presents a CRUD interface to the developer or a CRAP interface to the developer? So if you weren't there, the difference is CRUD is create, read, update, delete, and CRAP is create, read, append, purge. And the difference is in a CRAP model. I think it's, isn't it a archive purge? I'm not sure. I think it was. Was it a pen? Or is it archive purge? But so two differences, I mean, basically in the CRAP model, we generally assume that we're always making revisions. So we never actually update in place. And instead of deleting anything, we basically archive it and we might purge it later, actually delete it from storage, but that delete isn't an immediate operation. Now, you could make CRAP look like CRUD to the developer. You don't have to tell the developer that you're archiving. You could have a function called delete and behind the scenes it just flags it and doesn't actually delete it. But I think one of the questions we as a community need to decide is what, what do we want the API to look like? Do we actually want a function called node archive or we'd rather have node delete? I think people. What are the implications beyond being able to undo your deletes? I think under your deletes is one. I think one we'll discuss later is if let's say you're synchronizing content between sites. It might be better to synchronize the fact that you archived this node rather than trying to keep track of which nodes you've deleted, right? So you're basically synchronizing the current state of the node as archived rather than trying to keep track of the fact that you deleted it. And also it's basically a different approach to how revisions work because you just create a revision every time you edit or update something and you don't have to specifically say, okay, now I want to create a new revision. The code always does it, so, yeah. So when contained, you mean like using like a node reference or term reference field? Or do the, well, wait, but the fields never contain entities, do they? No. I mean, at least normally I think you use reference. Yeah, usually I think it's a reference and in 2.7 there's a module of field collection which basically works that way that you have a collection of fields that is another entity, but yeah, in the end it's just an entity reference too. So for modules like that, it would be actually, probably it would make sense to do it that way as I say that you create revisions of the field collection itself too because for the usage it should work like a whole entity. Yeah, but it's really in a certain case. Yes, everything would be revisioned, yeah, of course. So you would end up with some duplicated data and you would have to store more data, but the idea is that data isn't expensive today and you might want to have the data later on, so it's nice when the data is there. But still you need a purge operations and yeah, probably you want to be able to configure how the purge operation works automatically. So the question is whether it's either or for revisions. Yes, I think it would be fine, yes you could say that when you update you always create a new revision. I think the question here is more about what we present as the developer experience versus what the implementation is. So I mean we could definitely say yes, every time you call update it creates a new revision. That's fine and we could also say every time you call delete it marks the node as archived. Yeah, but I guess. They're not linked directly. I'm just, yeah, the real question is do we want, as a developer experience, do you want to think about archiving content for later purging or do you want to think about deleting it? What is the better developer experience or not even better, but like the easier one to comprehend, easier to comprehend. So and yes, then a sort of separate question is do we really want to revision every chain and make every change a new revision or is there ever a value to updating in place other than worries about storage? I think there are cases where people do insane things about updating extremely frequently. I think, are those actually valid or is that just broken code? So if someone has a use case where really I want to be publishing and unpublishing my content every five minutes or something like that, is that a valid use case or is there some, should you just have found a better technique for that, whatever you're trying to achieve? Thinking about comments, like we don't revision comments right now, but that also means if you want to go back to the state of the database, the state of your site an hour ago, you can't, right? Anything you update in place, you can't really go back but if you put revisions on everything, then you... Right, so then... You don't have everything in entities, but... Right, so the comment is, if you revision everything including comments, you potentially could go back to the state of your site at some point in the past, at least in terms of your content, which may be very useful for certain use cases also. That's the other time. Yeah. Personally, I think for the developer, it should be really be a grad interface because this is the interface that developers know today and they are used to using it, so I think it would be just another duplism if you would just have archive and not delete and we would have to teach that to all the developers. So I'm much in favor of a grad interface and I think still if you have a grad interface for developers, we could implement CREP and entity controllers if you want it. So we could have grad and CREP. Let each entity decide one way or the other, but it makes it more complicated, but making it not be a choice would, I think, be good just based on this whole issue summary thing we've been going through, I'm just thinking about that, you know, in Node, you can update in place or you can make a revision and it plays on the entity level, but that don't have a separate API for update in place versus revision. It's like for one entity, it's one way and for another, it's another way, but anyway. Right, so Jennifer's saying a single entity should not have both the option to update in place and have revisions regardless of how we move forward. So. Just a moment. Yeah. Ken? Yeah. But I think if you, I'm going to go back to what you said yesterday, what about data that I would consider to be stateless or not revisionable or not desirable to be revisioned, particularly access control data and a Node ownership? I mean, it's a really nasty problem. Say you're using taxonomy or access control, right? And you change taxonomy to revision two to revision three. That means you have a different access control rule for each revision. Yeah. But I think if you... Let's repeat the question. So Ken is saying revisions can make things really complicated for something like access control if you have different taxonomy terms on revision one and revision two of a node. Yes. Okay, so and Ken saying, so for example, if I want a field that really controls node access, perhaps I don't want revisions on that field. I want it to be the same across all revisions so that if the current user can see the current node, they could also see all past revisions of that node, basically. So, right. So what are the... Yeah. So if we go to revisions all the time, how do we solve this problem? I have to admit I haven't thought about it too much. I mean, I think the easiest case is you base something like access control off the current published revision or something like that for all the past revisions. But... That's the best of the facto state now actually because node access is not... I mean, there are legitimate use cases for saying the access control should change based on revisions today. I mean, that's a legitimate request. I won't decide on it. But it is a big problem to set up. So, I mean, somebody, the access to the current, to viewing the current, sorry, the access to the current node is going to be based on the current state of all of the fields, right? Correct. So that I make things, I... So that I don't have to deal with this problem. So Ken is saying he bypasses this problem in Drupal 7 by using his own tables and not using entity or field storage. Well, I mean, the menu system has the same problem. Right. So part of the problem is also things like paths on a node that you can't revision necessarily because the link that it's referencing is not revisioned along with it. So menu links and path aliases, are you asking should they be entities or are you saying... Yeah, good question. I mean, yes, probably links should probably entities. I mean, they are in this sense data. They really... You know, you can delete every menu link and your site still works, right? You can delete every node the site still works. You can... Path aliases... I don't know. I haven't thought personally about it. But my intuition would be not to make them entities, but I must say I haven't really given it a thought. We would have to... That definitely would need some discussion and we would have to need a look at that. Yeah. Okay, I think we should move on. Yeah, yeah. Okay, we're close to the end of the... I mean, it's a basic continuation that... Yeah. Fogo is going to do more himself. Yeah. And the second half. So it's basically containing for full. So also, yeah, Greg talked to us about UUIDs. So even if we're not focusing on that initially, clearly we have to have that in the back of our mind as how we handle UIDs. So for the sake of simplicity and speed, probably most operations like the load operation, the default will be to use the integer because if you're coming into a page, a path, you're going to have the integer ID handy. You don't want to have to go through the extra step of looking at the UUID. But clearly we're going to need to implement load functions that take a UUID either for an entity or for a specific entity revision. And one thing here is, again, if we're doing revisions, is there any use for having an integer ID for each revision or should we just have a UUID? So if you think again about reference fields, generally you only reference effectively the current revision, which is the shortcut to the current revision is the integer ID. So maybe there's no real cost to only using UUIDs to reference a revision, and that would make the code kind of simpler. If you're trying to load a revision, you always get a very specific thing based on a UUID rather than getting something that might be different on one site versus another site. So again, part of where we're going with this is to move to utilizing more of the OLL features. So we'd think about having a base class that implements some kind of interface that would be common for everything in core. Every core entity would do this. And once we do that, we can start again defining specific classes for each entity type. So a node class, a common class, a user class, a whatever class you want, and that would either probably extend a base entity class in a lot of places or at least implement this interface so that we always knew we could always check that object we're dealing with implements the right interface. And more specifically... We don't have standard class node anymore? Right, so we don't have standard class node anymore, and that means we can do actually better checking on our data. Right, so you could do... Alright, we'll skip ahead here. So in fact, if you have an operation that should only operate on a node, you can type int in PHP, right, and then PHP will throw an exception or fail what kind of fatal error it gives you. If you pass a standard class into this, it no longer works. Why do you need a function then? Well, this is just an example. So if you have some kind of function or some kind of method that only operates on nodes, as the suggestive... I don't think that we should do any other methods on nodes besides the methods in the entity interface because the entities really represent our data in Drupal so the object itself also should only deal about the data. So they are really the representation of our data model. And if you think about it, it's also the only way it can work because Drupal is modular and any module may provide further functions that work with nodes and you won't be able to get those all in the class anyway. So it's really the only way it is consistent across our modules. And I think it pretty much fits the vision of having entities representing your data in Drupal but not having entities to deal with anything or everything. And let's see if we back up. I think there's one more discussion point we wanted to hit. Maybe one back here. So there are a couple more discussion points we want to have. I mean, this is a core conversation. So when we think about having an entity interface, we're basically building on what we have in Drupal 7, which is that there's sort of a controller. And the controller actually, it's not the entity class itself that does the heavy lifting, it's a controller. And this is an abstraction that's a little confusing when you see it. But the value for this, especially as we move forward, is that we can have standard controllers so you define a new entity. I mean, in Drupal 7 already does this, you define a new energy type. A controller which already handles storage, already handles load, save, all these other things for you. And you don't have to embed all of that code in a default entity class that everything else is extending. And one thing we're thinking about for Drupal 8 is that we actually split this up a lot more. So for Drupal 7 there's effectively one controller for each entity type. And it handles every possible operation in the sort of CRUD cycle. Whereas for Drupal 8, perhaps we should make this more granular. So we have different controller for storage, for caching, for display, for maybe building an edit form, maybe a different controller for access to that entity. And by splitting that up, it would make it easier to customize the entity by basically substituting a different controller. So question, will every entity be commentable? Could be. Is it in Drupal 7? It isn't in Drupal 7. Right. I mean, in Drupal 7 we got close, but didn't go all the way to making comments, basically reference fields. So I think that's sort of a side issue to this. But I think that might feed into the display controller. Maybe the display needs to know if it pulls a reference comment thread. The idea of that is basically that you only need to have the storage controller and that all other controllers are optional. So you know you have methods to deal with your data. And then you have an easy way of enabling more controllers so you can enable display controller, form controller, access controller, and so you can easily provide entity types that do more or do less. And then also if you implement a new entity type, when you're implementing the form or the display, you can override and extend the controller to do your customizations in that way. So that brings us to the next discussion point, which this is really an open question. I mean, we're discussing and don't have an answer whether when you want to customize an entity type, do you want to focus the customizations on the entity class or on the controller? And an example of this is, I guess, comment module where it does some manipulations of the data on the comment. I think it maybe calculates the threading, some other things during the save operation. So should that kind of special logic, should that live in the comment class or should that live in the comment storage controller? Now there's sort of arguments both ways. So if you put it in the storage controller, maybe you end up having to replicate that code if you define a new storage for comments. If you put it in the comment class, it means you're kind of carrying around more code with comments. I don't know, what was the other, you felt like there's some downside to this? No, I actually can't think of any downside. So there's, maybe not obvious downsides, but it means that these entity classes move from being sort of a pure semantic thing where they just sort of reference their controllers and have some properties. Maybe the downside is that it's a little bit split up between the entity class and the controller which cares about the storage. So Thomas? So Thomas says another downside is you can't have sort of an external function that really invokes a save for an entity which you might want to do as a programmatic operation. You would always end up going through a class method or an instance method. Again, yeah, it's not clear that this is downside because maybe every time you save an entity you need to instantiate it anyhow. So then you have the instance and you call save on it. But it is a potential downside if we want to have sort of functional forms of a lot of these things where you can just call something like entity save rather than calling dollar node save. I think the main advantage of putting the customizations in the entity class would be that it makes it easier to make the storage controller pluggable. But if we really would go in the direction of the document or in the storage like Damian proposed it, it might be not necessary at all to have the controllers pluggable. So that's definitely a point we need to discuss further. Yeah, I think we have one more thing we want to discuss before Fagaro moves on to his section which was just a little more about document storage and kind of thinking ahead Drupal 8 and even beyond. If we decide the document-oriented storage is the right answer and the way we want to move then there's no reason we can't have different fields for each instance of an entity. So you could decide a particular node gets a file field and no other nodes of that node type have a file field, for example. And is that, you know, how valuable is that? Is that, you know, does that make things so difficult that we don't want to go there? Or is that add such great flexibility and really is that much better than sort of the bundle system we have now where every node is constrained to have exactly the same fields? So I think, you know, that's something Damian didn't really mention with document-oriented storage is actually really important implication of using document-oriented storage versus the relational storage we use now for entities. And so we can discuss now or we'll just leave you with this thought and move on to it. Yeah. Okay, so I think we just move on. Okay. So I want to shortly talk about the entity probability I. So if you think of an entity in Drupal 7, when you have the entity object in code and you just know it's an entity and you don't really know it's type, so the problem is with it you can't really do a lot of it, right? So in core, if you know the entity type, you can do some stuff like getting the label, the UI, and also it would be nice to save it once we have the graph thing in Drupal 8. So with the proposed stuff we talked earlier about it, basically we would be able to do stuff like that. But still we won't be able to have a look at what is inside the entity. So if you have an everyday entity object there, I think it would be really important that you are able to get a list of all the properties the entity has so you can actually do something with the properties. So you need to be able to get some information about the properties and also there need to be some handy little getters and setters that allow you to get and set the property values. Okay, Jennifer asked what a property actually is and when I'm talking about an entity property I mean something that is not a field like no status, not offer or so. But what my metaphor is about is making that property is more powerful and making them more similar to what a field is so there's actually not that much difference between those. So yes, that way I think a field should be a property too so that it's really working the same way. So when you have a look at the getters and the setters I think it's really important that developers can use them for feeds and for properties the same way. And additionally, if you look at the example just get me an property you need to know somehow what you're getting. So you need to have a property information which tells you what is the data type you're getting and is it the user? Is it just a numeric idea or stuff like that you really need to have some data information about it and I also think it would be nice to have some labels and descriptions included for some modules that make use of the properties in some UI. So actually there's some discussion we had with Ketch and Crello about whether we want to do some lazy loading of entities and whether we want to use some magic to trigger the lazy loading so in PHP you could implement a magic function underscore underscore get which then is automatically invoked if you access an entity property that is not there. So that way we could actually do entity objects that are not loaded so they contain only the entity ID and as soon as you access the property it automatically gets loaded. So that way you don't need to pass the entity ID and the entity type around anymore you could just instantiate an object which only contains the ID and is not loaded yet and pass it around. So we would have a more uniform API and developers don't have to deal anymore about specifically loading a certain entity if they only have the ID or is it loaded yet or not. The question is doesn't it imply that we don't need to get us and set us anymore? To some extent yes, but internally they still would use to get us and set us and also I'm not really a big fan of that idea because it really makes it difficult to track the code flow and if you just access an property you can't be really sure of what happens and if the developer does that he might not be aware of the fact that it might trigger some loading somewhere else. I think we need to be careful with that and also it might lead to some unexpected consequences if you just write an arbitrary entity and it triggers some code somewhere else you don't expect it and it really can lead to some strange side effects. So what we came up with is that we want to restrict that to the list of defined properties. So it is very important that we have something like a hook entity property info that makes it possible to define the list of properties that are actually available and then we can restrict the magic to that. Also additionally it would be just the default way of getting and setting a property to directly access it but in more advanced situations like when you need to get a property or a feel in a certain language or stuff like that it would be nice to have a gather where you can just specify the language option. Yeah, Peter? I mean I think it's still also worth saying I mean this list loading, yeah it's not clear whether it's actually a good optimization so probably it should be postponed until everything else is working. Yes, Peter mentioned that it's not clear whether it's actually a good idea to do and yeah it's really just an open point for discussion and not anything we are sure we should implement that. So this would be only to maybe say but if we have document oriented storage presumably most of the properties are all in fields and all the stuff about the entity you're all maybe stored in one place anyway so if you load one of them you get everything. Is that right? I'm not sure I've understood the question. What is it saving you to do this? What is it saving you to do this? Basically that you don't have to care about whether you pass around an entity ID or a fully loaded entity object so for the code that it's getting called you don't have to care anymore so that's the main advantage and that way you could actually end up with some optimizations that you pass around an entity object that actually in the end you never get loaded because some code decides oh I don't want to deal with that entity anymore and you just keep loading it at all so that way it might lead to some performance improvements. Also there are two different ideas of implementing that so catch came up with the idea of having it managed by the controller so that in the end each time you instantiate an entity object it's registered at the controller and then if loading an entity object is triggered the controller just starts and actually loads all the entities that have been registered in the controller so if there's a page and three nodes would be used in that page and as soon as the first node would be loaded the controller would be able to do an entity load multiple for that would lead some performance improvement Personally I'm not sure about whether we should do that because it might be a bit strange if you are using a single node and you're loading a single node and somehow multiple nodes get loaded and all the hooks fire up so it might be a bit unexpected for developers so a different approach would be that we do it only in a more declarative way so that we have something like an entity set class which allows you to create an object which basically represents an array of entities but which are not loaded immediately but are lazy loaded as you assume as soon as you use a single entity of the set and in regard to properties it's really important to cover some additional metadata so if you think about what you want to do with an entity and what you want to do to be able to do with an entity I think it's also a good idea to think of Drupal as an arrest server if you have each entity as an arrest resource what you need to be able to do and what you need to be able to know about the entity in order to make things happen so if you want to update an arbitrary entity you really need to know is the current user allowed to do the update so you really need to have property level access metadata so you know who is allowed to change the node order or not and so on and we basically have to write it now for fields but I think we really need to have a common API for that for all properties the very same way it's for validation if you are updating arbitrary entities based on the general fashion you really need a validation API that is decoupled from form validation but works generally so you could do just a web service called a safe an entity and if the data doesn't fit it needs to give you an error so we definitely need a validation API for that so we can handle that we probably want to look into how we can make a good validation API that works well for form validation too but it's decoupled from form validation and then there's also the need for having a translation for properties so I think it's really important to have each property being able to be marked as translatable so basically it behaves like a translatable field and all APIs need to be aware of that fact and need to take it into account so yep, it's really much similar to fields and I'm going to talk about that later on so in Drupal 7 I've implemented lots of them in the entity API module and it basically has some support for handling access validation and also it has a simple marker for translation for all entity properties so you could basically implement lots of stuff of that already by implementing the entity property information API of the entity API module in Drupal 7 but really the problem with it, it's not native it's just an additional layer of the entity system we have at core and ideally you want to use the entity wipe as it provides these are some classes that wipe the entity objects that allow you to make use of the API easily so it's really a separate system built on top of the core entity API we have and I think it's working already pretty well but the problem is just, yeah, it's not native we have wrappers and we don't want to have that we want to have the nice and pretty API out of the box so this is how it looks like for Drupal 7 it's a property information array for the node graded property and as you see it basically specifies and label and the type so the type of it, the state and what's really important here is that actually it's documented and defined somewhere how the data of a certain type looks like so for the entity API modeling in Drupal 7 I've just specified a date has to be timestamped so anyone who gets the date knows what he's getting and actually can do something with it then there's also some additional metadata like set a callback that specifies how the data is actually set on an entity and the permissions and description and stuff like that so for the data types I think it would be important that we have something like a hook that also specifies the data types that are available in the systems and the hook and the system has to come with a set of predefined simple data types that basically for the entity API modeling in Drupal 7 I've took the data types that are very similar to XML schema because it's a set of data types that is powerful enough to basically depict any data you need then you also want to have entities as supported as regular data types you can just say oh it's a user entity and we also need to have something like complex types so a data type is this compound and build of multiple other simple data types like if you think of a file field it actually has a file in the description and stuff like that so this actually is some kind of a data structure that exists of other data types and also build up in the data types we can also build other APIs so if you think of the storage API or a display API or forms API so I think of the demo and a widget API or whether something is compatible with something other so whether a property is compatible with a certain plug-in with a certain display plug-in or widget plug-in really should depend on the property information in particular on the data type so once we have a specified set of property information we really can build lots of components that are designed to work with a certain kind of data and the nice thing then actually is that you can give it any kind of data that fulfills the defined interface and it just works okay so let's have a look about how translation would work in that area so I think it really needs to be built in so that any property can be marked as translatable as I said previously then also the get-and-setter should really support an optional language key so you can get and set probably in a certain language if you want but we really need an easy way to access and set the default language by default so I think if you just access the property on the entity level it always should make use of the default language regardless whether the... so you don't have to deal with it whether the property is translatable or not if you don't want to have... if you don't want to care about that but if you want to access a certain language of a translatable property you still can use the dedicated get-and-setters to get and set the values Pina? Yeah I think we... Peter asked whether this should work for fields too and I think it's really important that we should make it work that way for fields too because right now this is really a developer experience issue that we always have that deeply nested data structure and we really should make sure that it's as easy as possible for developers Would this work with the current context level? Language? No I think there's something like an interface language and like a content language thread so I think different kind of languages and probably the entity type might want to have a way to specify what kind of language you want to use but basically I think we want to use the content language for that so this is how I would imagine that this actually could work and play together so we have a hook that defines property information and that defines how the entity properties actually look like and that basically would be the contract for everyone that uses an entity so the storage system really would have to take care about loading or storing entities that look exactly that way and then also all other systems that do something with an entity would also know what they expect they actually really would know okay this is the way the data looks like and this is the way the data has to look like when I want to write it back so we could do the display components and form components that really make use of that metadata and work exactly with the data as it is specified and actually the nice thing here is that we could start doing display and form components like we have them for the field API and make them work on top of the defined property information so we could go and start reusing that widget and display form models also for regular entity properties if we are able to decouple it and if we are just say okay they need that kind of certain data we can use them with any data and so we would be able to use them not only for fields but only for API level yes Klaus Klaus asks whether one has to implement hook schema anymore if one implements hook entity property info and yes I think we should do it that way but it really depends on the entity controller we built so in the third step it might be easier that we have just duplicated just as an interim step during development but in the end I think we really want to have just the hook entity property info from which the storage controller can derive all the necessary information for storing it okay so we don't have much time anymore but storage here I think the important thing is that the entity property information outlines the way the data has to look like and it has to store it that way it would be really simple to say we have something like a translatable note title because we only would have to care that the storage layer that the entity controller stores it in the appropriate fashion and the upper layers like the the formators and all the gathers and setters really don't should have to care how it's stored and later if we have some better automated storage system it could be even be handled in an automated fashion but I think the nice thing if we start with an entity property information system is that we could do it manually in the start and just implement manual entity controllers which just do it similar to like it is now and in the long term we can improve things and make it even more automated yes and also the question is how do we make the entity controllers swappable but we talked a little bit about that earlier already so I think the main question now is what is in property now, is it the same than a field or not and I think if we improve the property system that way it's really pretty much like an improved field API but it's more decoupled so we have field API decoupled in separate APIs that are reusable independently of fields so what I think then what a field ends up being is really just another property so I feel it's really just another property but which is custom and configurable so in a way that the user has defined this is a field and I have a new image on the node and a new file on the node but it's not defined by a module and it's not required by a module to work yes so the really important thing is fields and properties the interface should be the same but the question doesn't have to care ok, thank you