Vamsi, for your reference, here is the discussion on IRC in which nobody agreed on anything, but we all wanted to take over design of your project. We're just being enthusiastic, and there's some significant degree of <a href="http://en.wikipedia.org/wiki/Parkinson%27s_Law_of_Triviality">bike-shedding</a> here. In the end, you are the engineer, and aa is the manager; anything you design that's OK with him is fine. Your job right now is to listen to and participate in the discussion, but set a strict time limit (a few days, I'd say). When the time is up, you write up your design, get aa's OK, and then ignore us from then on :). (the IRC discussion below is tangled and confusing. At the end we agree to do it on this mailing list, so if you want to skip reading below, that's fine. I'm just posting it in case you want to see the sausage being made.) [11:08] <tomeu> homunq: have some problems following your last email about printing [11:09] <tomeu> what means "default action from journal for "print-me" pdfs"? [11:09] --> satellitFbe-74c6 has joined this channel (n=<a href="mailto:urk@208-100-132-172.bendbroadband.com">urk@208-100-132-172.bendbroadband.com</a>). [11:12] <homunq> tomeu: there would be some metadata besides mime-type, something like "sub-type" [11:12] <homunq> all pdfs created for printing would have a specific sup-type. This would make them "print-me" pdfs. [11:12] <tomeu> ok, what would that metadata be? which component would use that new property? [11:13] <homunq> sugar, when choosing which activity to use as a default, when several activities handle a given mime-type, would give preference to activities which have the same "sub-type" metadata. [11:14] <homunq> does that make sense? [11:14] <tomeu> why do activities other than Read need to open those pdfs? [11:14] <homunq> so both "print" and "read" would handle pdfs. [11:15] <homunq> "print" would be, within GSoC scope, an activity with no UI - just enqueue and terminate. [11:15] <-- eben has left this server (Read error: 110 (Connection timed out)). [11:15] <homunq> eben, we hardly knew ye. [11:16] <homunq> is that clear? And should I make the same clarifications on ML? [11:16] <tomeu> homunq: why do we need an activity with no UI? [11:17] <tomeu> homunq: enqueue should be pretty easy to do in the journal by using gtkprint [11:17] <homunq> um, because that's the work flow? [11:17] <tomeu> just like we don't have an activity for copying files from a usb stick to the journal [11:17] <tomeu> homunq: which workflow? [11:17] <homunq> I mean, there would be several versions/updates of the activity possible. [11:18] <tomeu> by sending a file to the print queue is quite trivial in pygtk [11:18] <homunq> the no-UI version is just alpha, for GSoC. [11:18] <tomeu> s/by/but [11:18] <homunq> what print queue? [11:18] <tomeu> and about the preview UI, why not just use Read? [11:18] <homunq> the moodle queue on the XS? [11:18] <tomeu> homunq: cups, lpr, whatever [11:18] <tomeu> the moodle queue, I think it's enough with file uploading in browse for now [11:19] <tomeu> that gives us authentication and is already done [11:19] <homunq> OK, so "print" activity is a spin of browse. [11:19] <tomeu> printing from the journal means for me to just submit a file to the local printing queue [11:19] <homunq> the local printing queue is meaningless. [11:20] <tomeu> homunq: well, it's the same thing you have in windows when you send documents to print [11:20] <tomeu> in most cases won't make sense, but it's stuff that it's already done [11:20] <homunq> yes but the moodle queue is the whole point of this GSoC [11:20] <tomeu> and will be important for a teacher printing from sugar to an attached printer, for example [11:21] <tomeu> homunq: ok, I don't think it's needed to implement local printing in this gsoc [11:21] --> J5 has joined this channel (n=<a href="mailto:quintice@c-24-91-155-241.hsd1.ma.comcast.net">quintice@c-24-91-155-241.hsd1.ma.comcast.net</a>). [11:21] <homunq> but we don't want to give every kid UI that only the teacher will use. Much confusion results. [11:21] <tomeu> so for uploading the file to moodle, can we just let the user use browse like would do for any other moodle-related stuff? [11:21] <tomeu> homunq: sugar will be used out from classrooms [11:22] <tomeu> homunq: want it or not, we are being asked to be able to directly print from sugar, and it's quite cheap to implement [11:22] <tomeu> homunq: but I would prefer if the gsoc project focused on moodle [11:22] <tomeu> don't worry about this now [11:22] <homunq> OK. So the workflow is: print to pdf. Resulting pdf has some "print-me" tag. Browse to upload - can search for "print-me" tag for easier upload. [11:23] <homunq> print to pdf is from inside journal, to journal. [11:24] <tomeu> not sure I understand the importance of that print-me tag [11:25] *** nubae1 is now known as Nubae. [11:25] <homunq> future enhancement is to do a spin of browse that handles PDF, and has a print-me menu item which will pre-fill the upload form with the given pdf. [11:25] <tomeu> but on the other hand, I think it may be good to start tagging entries automatically as we do stuff with entries, if it doesn't become cumbersome for the user [11:25] <aa> me neither... [11:25] <aa> homunq: I dont think we'll use browse to upload [11:26] <homunq> aa: neither did I but tomeu just convinced me. [11:26] <homunq> now I'm confused again. [11:26] <tomeu> what I like about uploading the file with browse to moodle is: it already works, kids will be already uploading files to moodle for other purposes [11:26] <aa> we just need an HTTP POST there [11:26] <tomeu> aa: we need authentication [11:26] <homunq> tomeu is right. [11:27] <tomeu> and progress tracking, allow the user to cancel the transfer, etc [11:27] <tomeu> not really just a http post [11:27] <aa> tomeu: the idea was to use XML-RPC for that [11:27] <tomeu> also, it's something we can implement in a later stage if feedback from the field proves me wrong [11:27] <aa> moodle has that [11:27] <tomeu> aa: I would really like to keep things as simple as possible [11:27] <homunq> I agree with tomeu. The quickest win is browse, the rest can come later. [11:28] <aa> well, if that's the case, I would leave queue management for later on [11:28] <homunq> aaak. [11:28] <homunq> is there anything that is not up for questioning here? [11:29] <homunq> I think that queue management, at least for the teacher, within moodle, is the heart of this GSoC. [11:29] <homunq> I could imagine punting on all but the simplest ("view") queue management for students within GSoC [11:29] <homunq> but teacher queue management is fundamental. [11:29] <aa> tomeu: the auth infrastructure currently being implemented by ML is just using the machine's public key [11:29] <tomeu> homunq++ [11:30] <aa> we can duplicate that code in the journal [11:30] <aa> yes, within moodle [11:30] <tomeu> aa: sorry, if we can avoid adding code to the journal, we should [11:30] <homunq> within moodle --> easiest with Browse. [11:30] <tomeu> we really really should [11:30] <bemasc> tomeu: I disagree. [11:30] * homunq lol [11:30] <aa> we are talking 10 lines... [11:30] *** jg_ is now known as jg. [11:30] <bemasc> I want an option on every item in the Journal: "print this". [11:31] <tomeu> correctly exposing async operations in the UI aren't 10 lines [11:31] <homunq> nobody agrees on anything, except that this is a great idea in their own head. :) [11:31] <tomeu> bemasc: I would like to as well, but for this gsoc, if we can avoid touching the journal and implement the desired functionality with a decent user experience, we should [11:31] <bemasc> homunq: which is why ultimately Vamsi will decide [11:31] <bemasc> tomeu: ok, sure. [11:32] <tomeu> bemasc: I talk mostly as a module maintainer here, I'm trying to find a solution that has a good balance regarding maintainability [11:32] <aa> tomeu: I'm talking about the auth code, which was your objection against doing a http post to send the file [11:32] <-- satellitFbe-74c6 has left this server (Remote closed the connection). [11:32] <homunq> tomeu: do you now understand what I am proposing? It touches the journal in the conversion to pdf step, not in the sending to queue step. [11:32] <tomeu> I'm sure you will find what I propose less elegant, but we need to be able to deal with the new code that will be created [11:32] <tomeu> aa: ok [11:33] <tomeu> homunq: yeah, I like that more [11:33] <aa> homunq: luckily there seems to be an agreement on how the activity API for this will look... [11:33] <tomeu> homunq: I would like to avoid doing the conversion to pdf in the journal, but I don't see how [11:34] <bemasc> we are experiencing one of the key problems with open projects: everyone's an architect. [11:34] <tomeu> well, it may not be a problem, we just need to deal with that condition [11:34] <homunq> and I am explicitly saying that the suggested list of cups filters is very limited, but that the actual list is distro-dependent. [11:35] <aa> tomeu: I think the pdf conversion itself can happen in the activity process [11:35] <tomeu> aa: I think it should be able to happen there [11:35] <homunq> tomeu: does that address your maintenance objections somewhat? [11:35] <tomeu> aa: I'm not sure if we can leave it to the activities in all the cases, though I would love to [11:35] <bemasc> aa: it can happen there, but I don't see why it should. Sugar is all about taking common functionality and moving it into the shell [11:35] <homunq> aa: have you read my email [11:36] <tomeu> homunq: well, we should probably avoid having to add conversion filters to the sugar platform [11:36] <aa> bemasc: I dont see a contradiction with that if the code is in the Activity base class [11:36] <tomeu> or we are going to end up specifying a full distro [11:36] <homunq> aa: I think "activities do the pdf conversion" should be exception not the rule. [11:36] <aa> which has been my proposal so far [11:36] <homunq> tomeu: why? [11:36] <aa> heh [11:37] <tomeu> homunq: the bigger sugar-platform is, the less space we let to deployers to adapt to their own realities [11:37] <bemasc> tomeu: I agree... which is why the conversion should happen in the Journal. [11:37] <bemasc> That way, the Journal provides an abstraction barrier between activities and the CUPS filter system. [11:37] <homunq> tomeu: I said they'd not be part of the platform, that they'd be extras to make a "print-enabled" sugar. [11:37] <tomeu> unless they decide to use a subset of sugar-platform, then some activities won't work, then the rationale for sugar-platform gets lost [11:38] <tomeu> homunq: what if some distro doesn't have one of those filters? [11:38] <tomeu> homunq: or have a different implementation of a filter? [11:38] <homunq> then it's not print-enabled? [11:38] <tomeu> bemasc: only in the journal? [11:38] <tomeu> homunq: well, but it prints ;) [11:38] <-- sirderigo has left this server (Remote closed the connection). [11:38] <aa> tomeu: we can parse /etc/cups/mime.conv and adjust to the provided filters [11:39] <bemasc> tomeu: right. If all printing goes through the Journal, then we don't have this problem. [11:40] <homunq> tomeu: yeah, that's the intent of having a "print-enabled" badge which you only get if you have this exact set of filters in an approved version of each [11:40] <bemasc> I don't think any of that is necessary [11:40] <homunq> printing behaviour if you don't have that badge is undefined, and that's OK. [11:41] <homunq> ie, enforcement is social, not digital. [11:41] <bemasc> oh, you don't mean this "badge" to be an actual software feature. ok. [11:41] <aa> so, we all agree that conversion to pdf should happen locally [11:41] <aa> (for reasons discussed in the list) [11:41] <bemasc> aa: that's a very general statement, and not true even in tomeu's proposal [11:41] <tomeu> guys, we should use the mailing list, or I'm going to get insane [11:42] <homunq> aa: good job, I didn't think there was anything we all agreed on but you found it. [11:42] <aa> tomeu: ? [11:42] * tomeu is also in #gnash talking about the gnash widget [11:42] --> satellitFbe-74c6 has joined this channel (n=<a href="mailto:urk@208-100-132-172.bendbroadband.com">urk@208-100-132-172.bendbroadband.com</a>). [11:42] <tomeu> aa: I think it will be easier to agree on something in the mailing list [11:42] <homunq> OK. I will clarify my proposal on ML based on this conversation. [11:42] <aa> ok [11:43] --> kushal has joined this channel (n=<a href="mailto:kdas@115.240.35.240">kdas@115.240.35.240</a>). [11:43] <tomeu> btw, I think we agree more than it seems ;) [11:46] <bemasc> vamsi is starting to get annoyed at us for taking over engineering of his project :-)