 Yeah, just look at the cute picture the baby for now. Oh This is about me So I'm Dave Reed. I'm a senior engineer at Palantir.net. I've been involved for Drupal for about seven years now I'm commonly known as the module hoarder So I write lots of modules. I probably in the last month have averaged one per week But I also maintain some some stuff that pretty much everyone uses like token and path auto redirect Media that kind of stuff So I've kind of been around the block a couple times I tried to do stuff with core as well not as much with Drupal 8 anymore And you may know me for my two adorable cats and almost one has a Twitter account And I just became a new dad last October which I'm really proud of and he will be making an appearance at the Palantir booth tomorrow afternoon And he has his own Twitter account as well I don't know. It's just fun stuff about me So what is this file management initiative? I haven't really heard too much about it What it really is is an unofficial initiative that we kind of started in some contrib space It's people that are involved at the media module and the file entity module and want to help encourage and develop and work on that support So it's kind of an unofficial initiative So what we've kind of been working on with this initiative is setting a roadmap For people we haven't been doing a very good job of keeping that roadmap updated unfortunately Encouraging people to be active in a bug squad in the file entity and media modules We've been trying to hold bi-weekly IRC meetings. Just kind of like the regular initiatives do Do just to kind of talk about things. What are we working on that kind of stuff? And there are some links to kind of our two main projects file entity and media And our IRC channel that we usually hang out is pound Drupal dash media So let's get into what we kind of set as our goals last year at Drupal con Denver So let's see the first thing that we want to do was make some configurable file types so one of the things about file entity is it basically extends the Very lightweight file entity in core And makes it fieldable and kind of adds a UI on top of core because you know with core by default All you all you can do is use upload fields that kind of stuff But you can don't actually interact with the data on the file itself. You're just using the file in places so file entity makes this kind of Expands this concept and lets you add fields to your actual files And it's really neat but one of the things that we need for this is we want to be able to make sure that you can group files into like Different types of files because you always think of your document files always kind of one file type your images as one file type your Videos as one file type and we want to make sure that we do that same thing in Drupal The tricky thing is When you go to add content, you're kind of doing the same thing. I want to make an article I want to make a basic page. You're kind of pre-selecting what you want to do When you have files, it's kind of the other way around you're like, hey, I have a file I'm gonna upload it. What is it? What is it gonna be Drupal? What do you what is it going to be? Is it in a document? Is it an application? and that's kind of the way that we've worked so far and That's kind of one of the things that we wanted to solve was this could kind of configurable file types Because how we had it in the past was we determined it based on the MIME type So if you uploaded a PDF, it was the MIME type of that files application slash PDF And so we say the first part of that. Okay, it's an application Which most people actually think it's a document. So it's kind of a disconnect there. So that was one of our goals to solve We wanted to make this experience of uploading a file a little bit better, too, and we'll go over that We wanted to kind of HTML5 kind of bring some more progressive solutions to file uploading, you know drag-and-drop You know plupload or those kind of things we wanted to try and encourage those solutions in core We wanted to add in for developers a file access API because that's kind of important You know should you have access to this file or not? It's kind of a kind of a thing people want to do We also wanted to add a metadata API for files. So things like image dimensions video dimensions Stuff that's read only that you can't really edit that should not be fields We wanted to provide a kind of a unified API for people to store this kind of data on the files Because right now what core is doing is it when you upload an image field it stores it in your field data And not associated with the actual file Which is a little bit backwards We wanted to improve the accessibility with images You know with this concept of fields we wanted to make sure that you know we're using alternate text and title text where we need to So we want to make sure that we improve that support We wanted to add HTML5 kind of audio and video tags You know it'd be nice to be able to upload an audio file and actually play it on your Drupal site without having to install too much And you know improving support for remote files because a lot of media does is you know Working with YouTube Vimeo that kind of stuff and we we does a lot to support that And so it'd be nice to you know build some of that into core and kind of help ease the burden and contrib and Lastly we kind of wanted to fix some assumptions that these core file and image fields make And we can kind of go through those such as we wanted to kind of fix what core does Because core assumes that you only use an image once in one place But what we're doing is media is we're using those files every everywhere We want to be able to reuse files and you know not delete them when you unused them in one time, so So what we did with configurable file types that's actually done and I'll kind of walk through what we did for that quick So you can actually just create file types in the UI and I've made a new screenshot file type and I say basically that it's it's mime types are Anything that includes image slash star so a wild card And we'll see how this works in the file upload to So I can just I can make any number of file types that I want now and I can actually determine what they should be It's a little bit tricky for people to configure mime types because That's kind of a system detail that people don't really know about For now we've provided like a listing of all the mime types, which is a giant list Which isn't very helpful. So we're going to figure out how to make this UI better And for the file upload process itself, we've kind of improved this a little bit It's now a kind of a multi-step form and kind of takes all these kind of steps Involved in it here. So I'll kind of show it quick Choose a file there we go So this is Rodney in a sink upload and we hit next and so now we see that I have two different file types that this file could be since it was an image and Because it can't determine what it should be We actually now it wants us to pick. Hey, is this a screenshot or an image? So it's kind of a nice way that we've solved this kind of multiple file type conflict kind of thing It should be up to the user to pick what it is If there's no conflicts, you wouldn't even see this part. It would just go to the next part So we say it's an image Next and Then another thing you get if you have multiple different Destinations that are writable in your Drupal file system. You actually get an option of where it should go Should it be a private file and live in your private file system? Should it be a public file? And again, if you don't have a private file system enabled you will not see this screen It's only visible if you have more than one enabled and So then last part of this is the actually editing the fields on this file So that's where you'd enter your alternate title text if you added extra fields This is while you'd enter them here. So that's kind of how we improved the upload UI a little bit Let's see For HTML 5 in core we have support for the multiple attribute in file widgets So if you hit that select files and then you select multiple files in your upload form It'll automatically work for you, which is an awesome improvement We don't really actually have true drag and drop. I know Dries actually demoed drag and drop in His keynote, but that's actually supported by your browsers into an upload field automatically. That's not actually Drupal specific I want to clear that up So we don't actually have drag and drop where there's like a target area where you drag your file Like you've seen in Google or WordPress. We want to actually try and accomplish that. So that's in progress right now Our file access API that is pretty much done in the file entity module. It's actually really nice It's got a helper function and hooks that you can use as a developer to say I want to allow or deny access to this user to this specific file on this operation So you could say the user can view this file in Drupal But not download it Which is actually kind of great for you know commerce solutions that kind of thing And we'd encourage people to build on top of this as well And this similar system is already built into Drupal 8. We just need me to tweak it a little bit based on the conversion that's happened For our metadata API We are still working on that in progress So currently in file entity we store it in an array of image dimensions on the file object But we prefer if it was stored in just a data array and I know you're thinking oh users data This is which to be an array where you can just dump everything We're going to handle it a little bit better than that where you have to declare What made a data you provide? And should hopefully restrict it to that So that's in progress Having the alternate and title text fields that's pretty much done. We've have them enabled by default on images We're still working The last little bit on making sure they're used everywhere like for instance in the media module that kind of thing For HTML5 just in general We have planned to support just some simple HTML5 stuff audio and video tags You know nothing too complex Just that would get local media playing and we also want to support like if you have a multiple file field You should be able to use You know a version that supports the track element for those multiple versions So it's one audio tag and multiple tracks for each of your field values Because that's one of the things that's possible with HTML5 like video. You can provide alternate versions or different tracks And that is in progress For handling remote files we have support and core pretty much done we built in some stream wrappers that Make things a lot easier for things that are read-only or remote That way they disable all the stuff that's writable And we can just easily extend those Some things that'd be nice to have are the system stream wrappers So you could be easily able to reference things in modules or themes with a stream wrapper And I've given some examples up there It'd be nice not to use Drupal Git path all the time In your own code Ironically the stream wrapper uses Drupal Git path for use is just invisible And for fixing kind of the assumptions that core has about these file and image fields What we've done is For every file and image field that you had on an entity It would actually have to go and fetch those files and load them Every time you load the node Whether you use those data or not We've actually fixed it So it just stays as a reference to the file ID When you load your node And then when it actually needs to display that node, you know, whether it's in the widget or in the view Then it actually fetches that node object So that way it just it caused performance issues And if you change something on your file, it wouldn't update the node as well Because it would cache the entire file object with it too. It just had some issues We want to make the file cleanup optional This is a long-standing personal issue of mine that if you upload an image in Drupal in an image field And you save the node and then you resave the node but remove that image Drupal will go through on your next cron and delete that image from your system Because you don't use it anymore. You didn't you didn't need to use it. There's no media browser in Drupal core Why did you need to keep that file around? Unfortunately, we're having a really hard time Not having that happen When we do stuff like media browser, you have to do stuff like adding file usage for every file that you upload to make sure it doesn't get deleted So we would really like to make that optional on core And there's just other things in Drupal 8 or possibly Drupal 9 We're trying to get rid of all of our different special reference fields that are special snowflakes And all get them to use entity reference Including file and image fields, which would be nice So there's a lot of things that are in progress and not done And this is kind of hits to our failure part. And I don't really consider it too much of a failure. That's a strong word We didn't meet our goals a lot of our goals. So why is that? Well kind of the project lead had a baby in october that didn't help a lot You know, it's great for him, but He kind of fell off and it wasn't able to communicate a lot of things And this kind of shows one of the points of our media initiative in this file management initiative Was supposed to be kind of decentralizing this information and this kind of project structure And I think it kind of proved that we didn't really hit that goal Of making sure that something could continue if someone got hit by a bus So we're going to work on that a little bit more You know, I will admit that there were some great people that actually took up Contributions and actually kept things moving forward. So it's not like Things completely stagnated and stopped moving And those people really helped out and that was really great We did lose resources too Just because of effort we lost I mean every initiative deals with this, you know resources come in resources drop off Were no special snowflake there That happened to us as well and kind of with The the communication we we used to have at meetings every thursday But we kind of fell off that radar is a little bit too and it kind of shows it's really important to have those meetings It's really important to be involved in the community communicating with people What's going on? How can I help if people have no opportunity to get involved or get to hit that meeting? I guess I'll move on and so that was kind of one thing we want to rededicate ourselves to So You know, can we still accomplish a lot of these things that we want to do? Any answer is yes We can do some of them from contrib we can try and get some stuff into core And some stuff we're just gonna have to postpone to Drupal 9. That's the reality of it That's the reality we all have to face to face as unofficial and official initiative owners We're still going to try and push for the metadata api into Drupal 8 core since it's a small feature That'll help other contrib developers We're going to work on finishing the file entity module in Drupal 8 contrib And we're going to Look at porting that and merging that into Drupal 9 And then we're also for the media side If you remember back on our goals that one of those first slides Media was actually not included in there And that's because we wanted to set low standards because I knew that we would miss some of them So we're going to still look at you know revamping this media UI retooling it Readjusting the UI and making it better Because we know it's it's not there yet So we're going to keep doing that and contrib and hopefully maybe merge it into Drupal 9 core. We'll see So officially what we want to target now for Drupal 9 things we've officially put off We once Drupal 8 is released we really want to get on file entity And merging that into Drupal 9 so getting that ported Into do all the Drupal 9 technologies and we want to have that happen as early as possible So that's going to be going to be one of our big pushes once Drupal 8 gets close And again, maybe the media module in core. We'll see how it's doing It's it's very possible And just the most part is we still need a lot of help You know Again, we we want to make sure there's lots of people invested if you're using media module on your site We would love your help, you know, whether it's documentation Testers people that can write simple tests or just want to test things We want that help So Where can you help? So we have some code sprints lined up, of course this friday at the venue And then we also have an official media sprint scheduled on in August at the Drupal corn camp in Iowa city I'm a midwest guy. So sorry. It's close to me But you know, if you want to organize a media sprint, I would love to put that on our group page and organize it And spread that information around too We're going to have our next thursday meeting at 20 utc Next thursday So come join us in the Drupal dash media channel for that And of course, you know, you don't have to wait for sprints. You don't have to wait for the thursday meeting. You can help out any time It's a little Little known detail there So that's really all I had to update on our progress. Um, so I'd love to invite questions What do you think of the file type selection? How does that work for you? Do you think we could do something better there? Um, do you have improvements for the the mime type selection? How could we improve that? Um, I'd love to hear your thoughts until uh, jesse's time at at five o'clock Go ahead steve So in this morning's core conversations with Mark Sonnenbaum and hay rocker we heard about Uh, what it could mean to have future releases of Drupal that don't break backwards compatibility potentially smaller Either 8.1 8.5 whatever we call it But incremental releases that add new features that don't break backwards compatibility Dries also mentioned that concept in his keynote. He also mentioned A desire to snap his fingers and get better media in core If we had that model of doing smaller feature improvement releases of Drupal core that didn't break backwards compatibility Is media a place where we could see improvement in core without breaking backwards compatibility? What could you do if if we had a policy of incremental improvement in core? That's a really good question about those incremental core releases You know that would definitely help out a lot of things You know things like the metadata api we could definitely target that more towards an incremental release um Having something as large as merging in the file entity module and making files fieldable That would probably have to wait for a new version of core Drupal 9 Just because it's such a shift in what we're offering and how files work for people And it introduces that different file type selection So it actually has to go through and reprocess all of your existing files Which is something I would be concerned about on existing production Drupal 8 sites But I would definitely love to have that official. Okay that we could add features like those my more minor ones Could definitely help out that shift and we can ease parts of file entity in if we could That'd be great if we could but it just it needs a official approval from someone named Reese All right. Thanks Dave. Thanks Thanks for all your your hard work I was wondering we have we've got managed files and then we also have these These high level concepts like like youtube videos And it seems like these are like really very different things and yet we're treating them as the same You know, we're treating a youtube video as a unix file system Would it not be better to have sort of two two different types of entities? So that's a very good question, you know should local Managed files and these kind of remote virtual files be considered differently. I mean like even a managed file That's on s3. Okay something different to your youtube video Got it. So just actual files versus a virtual file like youtube or vimeo. It's not even a file. It's like this Yeah, level thing. Well, I mean you have to upload something. It's a file You know, that's kind of how I consider it, you know YouTube has to serve you something in that flash container or it's html5 container. So it is it is a file I don't really think that we need to distinguish between the two. I think that may make things more challenging Um, I don't think we have really a whole lot of problems kind of you considering everything as a file Um, you know, if we did we would definitely we need to reevaluate that or if you know of any issues I would love to hear those So but until then I don't think we need to Okay, thanks. Yeah Thank you for all of your hard work. By the way, uh, just to echo that Um, how do you like how do you keep file entities small? Where do you draw the line? Like what makes something? Media and something file entity, you know, I'm saying like what's the Where's the delineation there? Where do we cross the line between file entity and media? um You know file entity we we try and think of it as You know, is this is this something we could easily merge into core like everyone could probably agree on? Yeah, that sounds really good Um, and kind of maybe has a low barrier to arguing Um, that kind of gives me an indication that goes into file entity If it has to deal with the fields, um, just If it's if it's anything in like the file slash one slash edit form That's typically a file entity thing If it's more on the widget side and you know selection of existing files that kind of stuff That's media for me. Um, so that's kind of where we try to draw the line there It's it's a gray area and we discuss it every time so All right, here's the fun question um Not actually about the comment earlier about like whether remote streams should be files or not It turns out to be really interesting. Um, like whether youtube streams, you know Can be thought of as files and the file entity and media approaches that they are And I I think there's lots of good reasons for them to be Um, but what's interesting is there's a couple other contrip projects that are out there that have taken a different answer to that question So there's asset module and they are scaldi module which have all done some really awesome work And I guess what I would love to see happen during the Drupal 8 contrip space is More interoperability between those three modules between media asset and scaldi So I think a great way for that to start is to yeah try to set up some meetings With with all of us and and look at these kinds of architecture questions of where the three projects have taken a different architectural approach And like how can we resolve those so that we can sort of have a base architecture that we agree on and let You know either the three projects merge or let them continue to be three projects, but that interoperate Yep, I now have spoken with the maintainers of asset and scaldi um And one of the big differences in these kind of approaches is really that concept of Do we want to reuse the existing file entities provided by core and extend those? Or do we want to just start with our own kind of asset entities or? That media entities and that's what media used to do is it started to use its own thing But it moved to this approach of reusing files And so that's kind of We're kind of in our in sticking the boots in the ground with with file entity that we want to do that I think there could be a lot more communication and cooperation with things like media browsing and Encouraging a lot of coordination in ui research for what's a good browsing A unified way to browse the ui whether you're using scaldi or asset or media I think we could potentially leverage some communication there So yeah, we'll definitely be continuing to talk with those maintainers as well Great session. Thank you. Um, I really support what Mr. Before me said and When we had our local camp like one month ago, I was very sad when their Company showed up that is developing another country module that handles the same things and Yeah, I think it's a waste of time and waste of resources and waste of energy. So And A lot of times when you ask those people, why are you doing that? I mean, it's just another module that reinvents the wheel And usually I hear an argument. Yeah, but media doesn't do this this and that so they would probably Go in if they would Have their problems solved also in media. So Yeah, and I don't want to nice to more Do achieve more cooperation between all these people. Yeah, and We don't want I don't want to speak bad about any project at all, you know People develop their solutions. I know I'm definitely the one to like All that solution sucks. I'm gonna go right my own. So I I don't want to I get caught up in that too Um, you know, we definitely want to cooperate and kind of coordinate where we can we've definitely You know opened issues. Hey, what are you doing? That's really cool that we couldn't do Maybe we can work on that and we've opened issues in those modules to try and do that Um, so yeah, we definitely want to keep coordinating and trying We would love to have one community solution, but we acknowledge that that's never going to actually happen There's always going to be separate solutions But we can maybe have the one of the most weight behind it. I don't know so Um, unless there's any other questions, I'll just get ready to hand it over to Jesse. So thank you very much Thank you