[2009-06-03 11::38:01] aaronwinborn: jmstacey: the main argument against it thus far has been more around metadata. 'why reinvent the wheel, or try to force everyone into yet another arbitrary method' [2009-06-03 11::41:29] aaronwinborn: jmstacey: arthurf & drewish have been on the camp that wants to be minimally invasive, so to speak, and defer to other modules when possible [2009-06-03 11::41:49] jmstacey: aaronwinborn: I agree about that, but at the moment it's almost as if the modules will have to handle all metadata and pass it back to media.module. Was that the intended route? [2009-06-03 11::42:11] aaronwinborn: jmstacey: kwinters has been on the other side, and i've been wavering on the fence about it [2009-06-03 11::42:57] aaronwinborn: that's how it currently is, at least as far as the (original filefield/emfield/etc) modules handling their own metadata [2009-06-03 11::43:27] aaronwinborn: in colorado last month, we talked about the rdf-media-bridge module offering another solution [2009-06-03 11::43:46] aaronwinborn: which would pass the data to rdf to handle, but create an interface in the browser for metadata [2009-06-03 11::44:18] aaronwinborn: that doesn't even get into the issue of formatters (which quicksketch just addressed in a recent module, forget its name right now) [2009-06-03 11::50:01] jmstacey: aaronwinborn: what happens with modules that want to use taxonomy rather than RDF? [2009-06-03 11::50:29] aaronwinborn: yes, there is that :P [2009-06-03 11::52:29] aaronwinborn: a media-taxonomy-bridge module? a media-noderef-bridge module? :P [2009-06-03 11::52:44] aaronwinborn: it gets twisty and curvy there [2009-06-03 11::52:48] jmstacey: aaronwinborn: hehe, seems like a slope that I don't want to be on [2009-06-03 11::53:27] jmstacey: I'll stick to they bunny hils :-P [2009-06-03 11::53:36] aaronwinborn: not to mention you're already getting a bunch of metadata from getid3, youtube, picassa, etc... [2009-06-03 11::53:56] aaronwinborn: and we haven't even begun to talk about how to pull and store that in a consistent method [2009-06-03 11::54:17] aaronwinborn: obviously, the media: youtube module would want to handle that, but would be nice to have at least some consistent hooks to call [2009-06-03 11::54:32] aaronwinborn: ideally [2009-06-03 11::54:36] aaronwinborn: what i would want [2009-06-03 11::54:56] aaronwinborn: would be to invoke something like hook_media_metadata [2009-06-03 11::55:19] jmstacey: aaronwinborn: and just give it an operation? [2009-06-03 11::56:00] aaronwinborn: yes. like media_youtube_media_metadata(), which would say, 'i have a title, description, youtube user, number of comments, votes, etc' and want to pass that for someone else [2009-06-03 11::56:26] aaronwinborn: and someone else has media_rdf_media_metadata() which says, 'give me all your metadata and i'll sort it out for you' [2009-06-03 11::56:32] aaronwinborn: personally [2009-06-03 11::56:57] aaronwinborn: i like kwinter's approach of having a single table that stores metadata in key/value pairs, and is agnostic about what goes in or how it's used [2009-06-03 11::57:22] aaronwinborn: but arthurf & drewish advocated against that and for using rdf, which already takes care of storing that data [2009-06-03 11::57:46] aaronwinborn: i just don't want to force that on anyone, if all they want is the title/alt that filefield/imagefield gives you [2009-06-03 11::58:03] jmstacey: aaronwinborn: what about microformats? [2009-06-03 11::58:15] aaronwinborn: otoh, if they want the full flexibility of rdf, getid3, what have you, would be nice to allow for that as well [2009-06-03 11::58:27] aaronwinborn: i haven't looked much into microformats [2009-06-03 11::58:42] jmstacey: http://microformats.org/ [2009-06-03 11::58:53] jmstacey: Google uses it on some of their services like map I think [2009-06-03 11::59:24] jmstacey: Of course, there's nothing written for Drupal that I know of. So that would be a project in and of itself [2009-06-03 12::00:14] aaronwinborn: http://groups.drupal.org/microformats-in-drupal [2009-06-03 12::00:31] aaronwinborn: not loading up for me right now [2009-06-03 12::00:50] jmstacey: works on my end [2009-06-03 12::01:25] aaronwinborn: looks like nothing in the past few months [2009-06-03 12::01:52] jmstacey: I just happened to know because the University events system uses hCalender [2009-06-03 12::02:14] aaronwinborn: http://groups.drupal.org/node/1890 has a good discussion too [2009-06-03 12::02:39] aaronwinborn: http://drupal.org/project/microsummary [2009-06-03 12::02:48] aaronwinborn: greggles is actively developing that, looks like [2009-06-03 12::03:18] jmstacey: last commit 51 weeks ago... [2009-06-03 12::04:22] aaronwinborn: oops [2009-06-03 12::04:28] aaronwinborn: i read 2009 for 2008 [2009-06-03 12::05:02] aaronwinborn: so yeah, jmstacey, looks like that whole area is a field of white snow, waiting for footprints [2009-06-03 12::07:40] jmstacey: aaronwinborn: ok. I'll need to process this over lunch. So, the current ideal solution up for weight is a hook_media_metadata(). Possible parameters are an multidimensional array $data, and a string $op for the operation being performed [2009-06-03 12::09:30] jmstacey: aaronwinborn: And we'll allow for registered metadata formatters as well. [2009-06-03 12::10:51] aaronwinborn: jmstacey: that sounds like a good beginning [2009-06-03 12::16:34] jmstacey: aaronwinborn: I just can't think of a way of tying RDF (or or any other context engine in) unless we provide a bundled file/meta engine or bridge (creating a file and metadata store "to rule them all" where all file operations must go through media.module followed by hook_file, and all metadata must go through media.module followed by RDF/Microformats/insert a dime a dozen context engine of our choice). [2009-06-03 12::16:35] jmstacey: Otherwise, we might as well let the modules deal with both providing file lists and meta information via hooks. [2009-06-03 12::16:58] aaronwinborn: http://packtauthor2009.posterous.com/announcing-packt-author-award-finalists [2009-06-03 12::17:07] aaronwinborn: gusaus: jmstacey: woot, i'm in the running! [2009-06-03 12::17:26] jmstacey: aaronwinborn: congratulations! [2009-06-03 12::19:00] gusaus: aaronwinborn: awesome! and it looks like you're one of 2 representing drupal [2009-06-03 12::19:24] jmstacey: aaronwinborn: I'm off to lunch. I'll be back online in about an hour. [2009-06-03 12::20:18] aaronwinborn: yep, hoping it goes to me or matt! i'd hoped at least one book in the finals would be a drupal book :D would be great for drupal if one of us gets that paperweight [2009-06-03 12::21:21] gusaus: ya - good buzzworthy stuff - front page drupal news? [2009-06-03 12::22:21] aaronwinborn: gusaus: good idea! [2009-06-03 12::23:29] gusaus: aaronwinborn: i already pinged amazon about it in #drupal-marketing [2009-06-03 13::36:29] jmstacey: aaronwinborn: ping, back [2009-06-03 14::13:39] jmstacey: aaronwinborn: vision for filefield? [2009-06-03 14::34:19] jmstacey: aaronwinborn: More specifically, #12 on http://drupal.org/node/377066. kwinters brings up a good point. I think ideally we would want a single file/meta set [2009-06-03 14::35:24] jmstacey: aaronwinborn: But I'm left scratching my head on how that can be accomplished without a central store of some kind [2009-06-03 14::57:28] aaronwinborn: jmstacey: that's the fence i sit on. i personally still like providing a central table for metadata -- that's what the files table is doing anyway; this would just extend that [2009-06-03 14::57:59] aaronwinborn: jmstacey: maybe it would be better to do this, but ensure it's in a separate module that could easily be swapped out w/ an rdf bridge module maybe [2009-06-03 14::58:16] aaronwinborn: jmontgomery: re. filefield, not sure what you're asking [2009-06-03 14::59:04] jmstacey: aaronwinborn: Was that meant for me? [2009-06-03 14::59:16] jmontgomery: i think so... [2009-06-03 15::00:24] aaronwinborn: erm [2009-06-03 15::00:27] aaronwinborn: jmstacey: rather [2009-06-03 15::01:03] aaronwinborn: old irc client let me choose nicks after choosing tab; this one makes its choice w/o my bidding :( [2009-06-03 15::01:57] jmstacey: aaronwinborn: you on a mac? [2009-06-03 15::02:07] aaronwinborn: linux/kubuntu [2009-06-03 15::02:27] aaronwinborn: used to use konversation; switched to quassel [2009-06-03 15::02:40] jmstacey: aaronwinborn: ah. I was going to suggest Colloquy. Simple, but it does have tab completion (best thing ever). [2009-06-03 15::03:15] jmstacey: aaronwinborn: My concern is the same as kwinters on what happens when a file is added to multiple filefields. [2009-06-03 15::03:35] aaronwinborn: yes, that's a big question that hasn't gotten answered afaik [2009-06-03 15::04:02] aaronwinborn: jmstacey: i guess that's where we decide how far do we go when overriding other modules' behaviors [2009-06-03 15::04:31] aaronwinborn: jmstacey: most of the metadata would be stored per file; filefield only stores title/alt [2009-06-03 15::04:35] jmstacey: aaronwinborn: I'm leaning towards answering that question before we get to far in and find out that we have to rewrite everything [2009-06-03 15::05:18] aaronwinborn: jmstacey: i would lean towards just storing everything w/ filefield, and filling in title/alt automatically from that (since in many cases we would be adding more metadata anyway) [2009-06-03 15::05:43] jmstacey: aaronwinborn: It would be a large migration, but what about forcing everyone to go through media.module (if they want to be part of the ecosystem).I'm just shooting from the hip but in a nutshell: [2009-06-03 15::05:46] aaronwinborn: jmstacey: we're already going to be overriding a lot of filefield's behavior anyway, as far as storing a single fid in multiple field instances [2009-06-03 15::06:16] aaronwinborn: and changing how files are stored in the first place (assuming resource module) [2009-06-03 15::06:55] jmstacey: we add a second table to store extra information to complement the new files table in D7. All module requests for files and meta would be handled by media.module and passed back [2009-06-03 15::07:51] jmstacey: aaronwinborn: that way we can fully use file_hook, and we keep things relatively clean compared to letting everything doing it however they want. [2009-06-03 15::08:36] aaronwinborn: that sounds reasonable at first glance [2009-06-03 15::09:00] jmstacey: Meta information would be serialized allowing modules to devise their own structure, but it would be encouraged to use one of the standards that we would provide [2009-06-03 15::09:02] aaronwinborn: i still think we should at least allow a hook for rdf, getid3, etc [2009-06-03 15::10:09] jmstacey: aaronwinborn: Down that route, a bridge like kwinters was talking about for rdf and others would become more feasible in my mind because then we can actually start mapping meta information from one to another. [2009-06-03 15::10:36] aaronwinborn: you make a strong case [2009-06-03 15::10:37] jmstacey: Each registered module would provide definitions for it's meta information to cross data over [2009-06-03 15::10:59] jmstacey: in the case that they wanted to use a custom structure [2009-06-03 15::11:22] aaronwinborn: why would we want the data serialized instead of just a string? [2009-06-03 15::11:30] aaronwinborn: makes it hard for queries [2009-06-03 15::12:03] aaronwinborn: i'd rather be able to write a views query, for instance, to find all albums from a specific band [2009-06-03 15::12:11] aaronwinborn: you can't do that if it's serialized [2009-06-03 15::12:24] jmstacey: aaronwinborn: True, it does make queries hard and extremely resource intensive so we would have to be very careful with the implementation, but it's very flexible [2009-06-03 15::12:57] jmstacey: modules wouldn't have to add or remove tables form the media_meta column, they would just change the data object as seen fit. [2009-06-03 15::13:20] aaronwinborn: what other data models would someone want? [2009-06-03 15::13:24] aaronwinborn: they seem fringe to me [2009-06-03 15::13:47] jmstacey: I got the idea from the Wordpress database which uses the serialized array to store information like image dimensions and EXIF data [2009-06-03 15::14:22] jmstacey: I do think that some of it should be normalized, but then we do run into the issue of forcing meta information onto the other modules. [2009-06-03 15::14:44] aaronwinborn: still seems fringe. most metadata would be a string. seems it would still be better for a module to serialize it on their own in that case [2009-06-03 15::14:57] aaronwinborn: i think it's better to allow for easy views queries [2009-06-03 15::14:58] jmstacey: Then again, we wouldn't need to require any of the extra information. Pop on an extra column and then the module can add whatever customized data they wanted to be it a string or serialized object [2009-06-03 15::15:21] aaronwinborn: that's an idea [2009-06-03 15::15:44] aaronwinborn: getting into the realm of flexinode, but i think it would allow for flexibility and speed [2009-06-03 15::16:23] jmstacey: aaronwinborn: hehe, you mean cck? [2009-06-03 15::16:53] aaronwinborn: no, flexinode :P as i recall, it had columns for string/number/serialized [2009-06-03 15::16:56] aaronwinborn: in a single table [2009-06-03 15::17:02] aaronwinborn: i have to go for awhile [2009-06-03 15::17:50] jmstacey: ok, I'll brainstorm a bit more [2009-06-03 15::18:04] jmstacey: and hide from the wrath of arthurf :-P [2009-06-03 16::56:48] aaronwinborn: jmstacey: i think the whole metadata/microformats discussion could use feedback from the larger community as well: maybe we could summarize this conversation and post it at gdo [2009-06-03 16::57:09] jmstacey: aaronwinborn: I agree [2009-06-03 16::57:11] aaronwinborn: like you said, i'd rather do it right the first time than have to go back and redo it later [2009-06-03 16::58:04] » StefanWray left the chat room. [2009-06-03 16::58:30] jmstacey: aaronwinborn: Would you like to do the honors (gdo)? [2009-06-03 16::59:05] » schock_ is now known as schock_nk09. [2009-06-03 16::59:43] jmstacey: After reading a bit more I don't think microformats is the way to go, at least if we want to stick with W3C. [2009-06-03 17::00:14] aaronwinborn: jmstacey: i probably couldn't until tomorrow. feel free if you want :D i'll comment in either case [2009-06-03 17::00:45] jmstacey: aaronwinborn: ok [2009-06-03 17::01:23] jmstacey: RDF might well indeed be a good choice but I'm trying to find out if data is really stored in the database in serialized form [2009-06-03 17::02:49] jmstacey: At least just looking at the schema doesn't seem to indicate any clear subject, predicate, object columns. [2009-06-03 17::05:21] jmstacey: If this is the case the we may want to look into creating a new module hook_meta to complement hook_file to provide a simple key/value meta system. From there a syncing bridge to RDF/microformats etc. would be easier. Anyways, pulling things together for a post on gdo. [2009-06-03 17::05:38] aaronwinborn: yeah, that would be a great idea [2009-06-03 17::05:43] aaronwinborn: is there a metadata project? [2009-06-03 17::06:17] aaronwinborn: there you go; it's an empty namespace right now if you want to start a new project for it, jmstacey [2009-06-03 17::06:46] jmstacey: "hook_meta" or "metadata"? [2009-06-03 17::07:07] aaronwinborn: metadata is better: hook_file was a horrible name. too confusing for development [2009-06-03 17::07:22] aaronwinborn: even meta is ok [2009-06-03 17::07:31] aaronwinborn: i think metadata is more clear [2009-06-03 17::07:36] aaronwinborn: about what it does [2009-06-03 17::07:44] jmstacey: sounds good to me. [2009-06-03 17::07:59] jmstacey: Shall we hold off creating the project page until we hear some feedback? [2009-06-03 17::09:14] aaronwinborn: might want to claim the namespace, but either way. if someone jumps on it in the next day or two, we can try to recruit them, or start a different project if their goals are too wildly divergent .... [2009-06-03 17::24:26] jmstacey: aaronwinborn: Possibly an entirely different discussion, but I was thinking about it along with hook_meta (now metadata): should file management also all go through media.module and in turn hook_file. We'll need a way to 1. track resources like youtube://movie that we can't put in the files table and 2. track additional information such as the registered module for a particular resource. [2009-06-03 17::24:28] aaronwinborn: gusaus_: not sure which elitists you're talking about :D open source is a do-ocracy anyway. the people who do things are the people who get to decide what gets done [2009-06-03 17::24:33] kreynen: built on straight profile and views [2009-06-03 17::24:56] jmstacey: aaronwinborn: In the end, using the files table, with a new media_resources, followed by metadata [2009-06-03 17::26:12] kreynen: that JQuery can take any multiselect that rates a skill 1-5 [2009-06-03 17::26:22] aaronwinborn: jmstacey: yes, file management should go through media.module, then to resource.module, then to hook_file.module (unless we decide to implement that w/in resource.module). hook_file.module was never part of the discussion per se; i just did it to get another ball rolling