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
bike-shedding
<http://en.wikipedia.org/wiki/Parkinson%27s_Law_of_Triviality>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=
u...@208-100-132-172.bendbroadband.com).
[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=
quint...@c-24-91-155-241.hsd1.ma.comcast.net).
[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=
u...@208-100-132-172.bendbroadband.com).
[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=k...@115.240.35.240).
[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 :-)
_______________________________________________
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
