Hi Martin, I am sold with the blocks concept ;) Though: I have finally wrapped things with the XML-RPC stuff for assignment-clone (which is print) module My idea was "do anything new only after having a backup". But there's still the authentication stuff that's at question. How do i tell moodle this is from an user X and how do I tell moodle that this will go into a particular course module ( I see no way to beat this without having a selection UI in the client). I have attached the module. There's a test.php script you can run to check how the xmlr-rpc code works. And I am very well ready to do a switch to a block, provided I have this all setup, so I don't mess my GSoC schedule. ;) Thanks, Vamsi <div class="gmail_quote">On Fri, Jul 17, 2009 at 1:56 PM, Martin Langhoff <<a href="mailto:martin.langhoff@gmail.com" target="_blank">martin.langhoff@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Hi Vamsi, Good hint from Tim -- Using a block is a much better approach :-) -- blocks are also "for something else" but we can make it happen if we are careful about a couple of things... So it's good to make a new block. I assume you can look at the block guide a bit, and draft a simple initial block -- do ask for help if you get stuck in that. I trust you to design how it works :-) There are acouple of "special" things I think you want to be careful with, because we are not making a conventional block. These are tricky points. I read my own email 3 times to make sure it made sense :-) I am also copying Mihai Suncan - he is working on a different project that (I suspect) has to solve a similar problem (in #2 below). 1 - Blocks can be displayed in any 'course page'. In our case, it will usualyl be displayed in the "Homepage" (which is a course page, actually, the course page of a special course that is called the 'sitecourse', identified by the SITEID constant). If it is displayed in a conventional course page (non-'sitecourse') it should probably show the same data. So the _context_ (in terms of access control API) in which it is displayed does not matter much -- it is a matter of convenience to the user. So you want to mostly _ignore_ the context that the Blocks API gives you, and make a lookup for the context of the "system context". You want to ask whether the user has printing / print-queue-management rights in the system context, instead of in the course context. 2 - You will need to transfer the data from the Journal to Moodle, store it somewhere, one of the key things is "in which security context / in which course". The other one is "how to handle the transfer". 2.1 - For the security context / "which course" question, my recommendation is to use the 'sitecourse' in Moodle 1.9.x -- this is not entirely correct, but I think we can make it work. We need to look up exactly how we can store those files in a way that is private for each user (so they are not browsable by anyone on the 'files' UI). For 2.0 (and for 1.9.x if the above doesn't work) we need to catch up with Petr to see how "user" files are handled in the new Files API. If/when we go this way, we will want to use the 'CONTEXT_USER' context. If things are not ready in the API, it will be awkward. 2.2 - The transfer! Moodle's existing API won't give you much here, neither in 1.9.x or in 2.0, but there are good tools to do what we want. 2.2.1 You _will need to make a specific entry point to transfer the files to_, a URL inside the block directory. We don't want to hardcode that in the Journal side, so let's hardcode a canonical URL in the Journal ( <a href="http://schoolserver/printqueue" target="_blank">http://schoolserver/printqueue</a> ) and we'll use a redirect or an alias to point it to the right file in your Moodle block. 2.2.2 The files to print can be large -- very large. HTTP is not very good transferring very large files, and Apache+PHP on the server side only make it worse (in memory use in particular). I am being polite here -- it sucks. It's unworkable. One thing we can do is to use WebDAV which is HTTP but it has all the smarts needed to transfer large files in many little chunks. One the Journal side, you need to identify a good python lib that can talk WebDAV. Does not need to be fancy but you _will_ want something that has a big "turn on debugging" option so you can see what's happening :-) On the Moodle side, we can use the PHP WebDAV libs to make a "magic" webdav folder that acts as a "blind dropbox"... a directory that looks always empty, but that you can transfer files to (and returns an OK code when the transfer succeeds). I wrote a "Moodle WebDAV" patch about 2 years ago that can be a good source of inspiration. My patch does a ton more, so you only need... 5% of it. hth, martin <div><div></div><div> On Tue, Jul 14, 2009 at 5:18 PM, Vamsi Krishna Davuluri<<a href="mailto:vdavuluri@acm.org" target="_blank">vdavuluri@acm.org</a>> wrote: > > I finished writing a course module, but anyway. I > I talked to Tim Hunt from Moodle. > And we had a very lengthy discussion to port this into a Block. > A block would have the advantage of being used anywhere from > moodle, and also enable us to have global notifications. > This seems much appropriate. > > 12:21:45 PM) Vamsi Krishna D: <a href="http://pastebin.be/19720" target="_blank">http://pastebin.be/19720</a> > (12:26:55 PM) Tim Hunt: Great! > (12:27:48 PM) Tim Hunt: So one question, is how does the teacher get to the > 'Print submissions page'. Presumably that is a link, but where is the best > place for it in Moodle. > (12:27:56 PM) Tim Hunt: ? > (12:29:04 PM) Vamsi Krishna D: he would have to enter the activity in my > vision. But I suspect having it in his global notifications would be best > (12:29:33 PM) Tim Hunt: Yes. I think using a block lets you put the global > notification on any page. > (12:30:45 PM) Tim Hunt: My feeling is that this whole system should be > loosely coupled to Moodle, and an assignment must be strongly coupled to a > course. > (12:31:00 PM) Vamsi Krishna D: Okay, can i reuse any of my code :p > (12:31:34 PM) Tim Hunt: Sure. I think the code that does the actual work is > the same, it is just a question of where you put it. > (12:31:46 PM) Tim Hunt: The code for integrating to Moodle would be > different. > (12:32:45 PM) Tim Hunt: The good thing about blocks is that there is quite > good documentation for how to make one: > <a href="http://dev.moodle.org/course/view.php?id=2" target="_blank">http://dev.moodle.org/course/view.php?id=2</a> and > <a href="http://docs.moodle.org/en/Development:Blocks" target="_blank">http://docs.moodle.org/en/Development:Blocks</a> > (12:34:12 PM) Tim Hunt: I suggest that the block just gives a summary like > '3 print jobs awaiting approval' with a link to a separate > blocks/printingmanager/approve.php script that does most of the work. > (12:34:49 PM) Vamsi Krishna D: so that would be like my submissions.php? > (12:34:59 PM) Tim Hunt: And for students the block can have a link, > something like 'Upload your print jobs here that takes them to a > blocks/printingmanager/submit.php > (12:35:22 PM) ***Tim Hunt goes to look at submissions.php > (12:35:53 PM) Vamsi Krishna D: which calls a function submissions.php in > lib.php :p > (12:36:00 PM) Vamsi Krishna D: submissions() > (12:36:01 PM) Vamsi Krishna D: * > (12:36:22 PM) Tim Hunt: Well, submissions.php has lots of code specific to > being an assignment in a course. Most of that could be deleted if this is a > separate script linked to from a block ;-) > (12:36:52 PM) Vamsi Krishna D: Ah! > (12:37:12 PM) Tim Hunt: Yes, it looks like you could move the code from > submissions() to blocks/printingmanager/approve.php - or whatever you want > to call it. > (12:37:56 PM) Vamsi Krishna D: excellent! > (12:38:33 PM) Vamsi Krishna D: Martin was also suggesting something better > than Course modules > (12:38:45 PM) Tim Hunt: What did Martin suggest? > (12:39:24 PM) Vamsi Krishna D: In my opinion, your code should not be a > moodle module. We need to > organize a skype / sip / irc chat to discuss where it would 'fit' in > Moodle. There are other APIs in Moodle that may be a better place. > > Or perhaps it doesn't fit any API and we need to craft a patch. > (12:40:03 PM) Tim Hunt: Ah I think I have not said anything that Martin > woudl disagree with ;-) > (12:40:17 PM) Vamsi Krishna D: Great! > (12:40:32 PM) Tim Hunt: The only other option I can think of is to put your > code in the /local folder, which is designed for miscellaneous hacks. > (12:40:40 PM) Tim Hunt: However, I think a block is better. > (12:41:05 PM) Tim Hunt: But might be worth emailing Martin a summary of what > we talked about, to make sure he agrees with what I have said. > (12:41:09 PM) Vamsi Krishna D: let me mail Martin and my mentor about this > concept > > On Tue, Jul 14, 2009 at 5:57 AM, Martin Langhoff <<a href="mailto:martin.langhoff@gmail.com" target="_blank">martin.langhoff@gmail.com</a>> > wrote: >> >> On Thu, Jul 9, 2009 at 1:15 PM, Vamsi Krishna >> Davuluri<<a href="mailto:vamsi.davuluri@gmail.com" target="_blank">vamsi.davuluri@gmail.com</a>> wrote: >> > Thanks to a kick start from Andres, I'm working royally with >> > moodle. >> >> Excellent. Sorry about taking so long. >> >> > so anyway, despite reading the reference site on the function: >> > I couldn't figure out how it works. >> > >> > has_capability('mod/print:submit', $this->context) >> > how exactly does this function work? >> >> Let me see if I can shed some light... >> >> - A module is _always_ used as part of a course. Modules implement >> the behaviour of a 'module instance', (think of it in OOP terms). So >> for example mod/forum code handles "a forum in a course", which is a >> "modinstance" (module instance) in moodle internals lingo. >> >> - Each modinstance has a "security context" - sec contexts are >> nested, like this: Site -> Category -> Course -> Modinstance. >> >> - The $context object you have there refers to the context of the >> specific modinstance you are dealing with (again, in OOP-ish terms, >> though moodle's modules aren't strictly OOP). >> >> With that background laid out, the code >> >> has_capability('mod/print:submit', $this->context) >> >> will return true or false answering the following question: >> >> does the currently logged in user have the >> capability/authorization to do "mod/print:submit" >> in the context of this module instance? >> >> Now, this won't make much sense in your case because printing is not >> about stuff "in a course". >> >> In my opinion, your code should not be a moodle module. We need to >> organize a skype / sip / irc chat to discuss where it would 'fit' in >> Moodle. There are other APIs in Moodle that may be a better place. >> >> Or perhaps it doesn't fit any API and we need to craft a patch. >> >> cheers, >> >> >> >> m-- >> <a href="mailto:martin.langhoff@gmail.com" target="_blank">martin.langhoff@gmail.com</a> >> <a href="mailto:martin@laptop.org" target="_blank">martin@laptop.org</a> -- School Server Architect >> - ask interesting questions >> - don't get distracted with shiny stuff - working code first >> - <a href="http://wiki.laptop.org/go/User:Martinlanghoff" target="_blank">http://wiki.laptop.org/go/User:Martinlanghoff</a> > > </div></div>-- <div><div></div><div> <a href="mailto:martin.langhoff@gmail.com" target="_blank">martin.langhoff@gmail.com</a> <a href="mailto:martin@laptop.org" target="_blank">martin@laptop.org</a> -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - <a href="http://wiki.laptop.org/go/User:Martinlanghoff" target="_blank">http://wiki.laptop.org/go/User:Martinlanghoff</a> </div></div></blockquote></div> <input type="hidden"><input type="hidden"><div></div>