21:23:17 #startmeeting 21:23:17 Meeting started Thu Dec 3 21:23:17 2009 UTC. The chair is PhrkOnLsh. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:23:17 Useful Commands: #action #agreed #halp #info #idea #link #topic. 21:23:18 ;) 21:23:32 #meetingname some backend talk on fedora-tour 21:23:32 The meeting name has been set to 'some_backend_talk_on_fedora-tour' 21:24:12 mchua: i'll see what i can do about an IRC meeting, although they are both pretty busy 21:24:12 mchua: so I am thinking that, instead of basing the content layout on how it is in the file system, to have an XML file that describes the content of each particular package 21:24:51 mchua: But i am not exactly sure of how I should be handling it; should I put those XML files in a different location on the filesystem, or in the same directory as the root of the content files? 21:25:08 PhrkOnLsh: back up a bit - what are the tradeoffs of each choice? 21:25:12 i.e. why would we pick one over the other? 21:25:24 mchua: well, from a technical standpoint. 21:25:33 BenjaminKreuter: np, thought I'd put it out as an option, that's all :) 21:25:43 On the one hand, you have a single directory where all content resides, and is easily manageable 21:26:16 or you have two (or more in the future) directories where in one you have content descriptors, and in the other you have content 21:27:06 The way I understand it, UNIX philosophy is keep data separate from applications (hence /bin and /usr and /etc and such) 21:27:16 but I am not sure, from a technical standpoint which would be easier 21:27:36 * mchua nods, data and apps separate 21:28:07 PhrkOnLsh: I won't give you an answer, but I'll try to help you think through this ;) 21:28:21 right now, the top of the XML descriptor has an entry describing where in the filesystem under the /usr/share/fedora-tour/content or wherever it will be placed. But if we have the XML stored in the same place, I am wondering if such an entry would be necessary, or even helpful 21:28:23 it's also a fine question to ask on #fedora-devel, where more coders hang out 21:28:29 mchua: that works well :-) 21:28:43 (making me think through it) 21:28:51 PhrkOnLsh: okay. "technical standpoint" is pretty broad, so let's consider several cases here. 21:29:01 PhrkOnLsh: one is translation - which do you think would be easier to do i18n with? 21:29:47 well, seperate directories, elsewise you will end up with overview-en.html overview-ru.html etc, in a single location, which is probably really messy 21:30:01 having content-enUS, content-enGB, etc 21:30:29 would make more sense in terms of translation 21:30:35 Yep, and that way it's easy to just download the languages you care about as well. 21:30:54 +1 21:31:09 Ok, that's i18n. How about code maintenance? Will one of these need less code, code in fewer languages, more widely-used languages, need to be updated more often, etc? 21:31:15 * mchua notes that XML is a language 21:31:35 iow, there are people that can do XML, people that can do python (for example) and people that can do both 21:32:00 well, the XML description would probably exist either way. The XML is content writers' job, whereas the python maintenance would be code maintainers' job 21:32:16 if you require someone to know both python and XML to help code, that's a higher barrier than being able to say "you can help with python, or XML, or both if you know both" 21:32:19 * mchua nods 21:32:24 that's good design :) 21:32:38 (and the reason we separate content and apps) 21:32:55 The XML file basically just gives the layout of the files and a few display details 21:33:01 I can pastebin a quick idea I wrote up 21:33:03 ok - does either design make the XML and python more or less independent of each other? 21:33:06 * mchua nods 21:33:29 http://pastebin.ca/1700855 21:33:32 * mchua will have to head out in ~5m, but we'll see what we can get through in that time 21:33:32 hmmm 21:33:39 oh okay 21:33:57 * PhrkOnLsh notes that the XML entities would need to be localized? 21:34:04 Is that even possible? 21:34:11 PhrkOnLsh: the tags? or the content in the tags? 21:34:20 mchua: the tags 21:34:31 Package, DisplayName, etc 21:34:35 I would worry less about those, honestly 21:34:39 okay 21:35:08 would that be feasible from a code standpoint? do-able with pot files? (i don't know a whole lot about i18n tbh 21:35:36 as for the python/XML independance comparing one to the other, I'm not entirely sure 21:35:49 The way you have it now leaves it open for the tags to be i18n'd, imo, but that's not a first-release feature to worry about. 21:36:02 okay 21:36:30 PhrkOnLsh: also, does either design just make you *happier* to think about than another? 21:36:46 honestly, I'm really leaning towards keeping things seperate 21:36:48 Or... another way of thinking about it - which one is easier for you to explain to someone else? 21:36:51 * mchua nods 21:37:02 From everything you've said to me so far, that makes sense. 21:37:12 from a packaging standpoint, it's cleaner (directory ownership, etc) and looks nicer, and probably easier in code 21:37:23 thanks, mchua :) 21:37:34 You know what I'd do? I'd blog a description of the two designs (a few sentences for each) and why you're going with the one you want to go with 21:37:50 hmm, that's a good idea. 21:37:54 and you'll either get "yeah, this makes sense" comments or "have you considered X?' comments 21:38:05 +1 on that 21:38:34 I gotta jet now, but this is - every time I peek in here and see the logs and convos, it totally makes my day 21:38:36 any last words, then? 21:38:43 just that you're doing a great job and keep it up :) 21:38:44 cool :) 21:39:02 thanks 21:39:02 #endmeeting