Re: [Server-devel] Some notes on the What you paint is what you get
Op donderdag 26 maart 2009, schreef Martin Langhoff: > On Wed, Mar 25, 2009 at 10:53 PM, Alex Wulms wrote: > > paint module on top of the dojo toolkit, which provides a cross-browser > > 2D graphics sub-library. > > BTW, I suspect that the approach of talking directly to modern > browsers' low-level APIs for imaging (canvas, etc) will outperform any > abstracted toolkits like Dojo. > > I mention this because performance _is_ critical for this -- the main > goal is that it works on the XO, where performance is not a given., > and not trivial. If you have an XO, compare the performance of Mihai's > Paintweb (which uses canvas, but is not optimised) on it vs your > normal computer. I can borrow an XO at work. Will have a look at the performance. Interesting discussion on the moodle forum. Will give it some thought. Kind regards, Alex > > cheers, > > > m ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] Some notes on the What you paint is what you get
Hi, We are currently investigating how easy/complex it would be to make the finger paint application as a TinyMCE module/plugin. We would like to build the paint module on top of the dojo toolkit, which provides a cross-browser 2D graphics sub-library. Dojo toolkit is available under the BSD license and under the AFL (see http://dojotoolkit.org/license). Do you know if one of those two licenses would be compatible with the GPL license used for moodle and the LGPL license used for TinyMCE? Thanks and kind regards, Alex Op woensdag 25 maart 2009, schreef Martin Langhoff: > Alex Wulms was recently asking for some detail on this in a private > conversation -- the revelevant bits below... > > [ to everyone involved, let's have the conversations via server-devel :-) ] > > On Thu, Mar 19, 2009 at 11:16 AM, Alex Wulms wrote: > > Regarding the finger painting application: at the moment we don't have > > much information about what is expected about it. > > > > Here is the info that we have: > > --- start of info > > * Moodle is the Course Management System / Learning Management > > System. It is the "main face" of the webbased tools that the > > School Server offers. Most of online (webbased) interaction is via forms > > -- a text-heavy approach, thus aimed at older kids. > > * Young children find it easier to paint and draw. > > * If we can switch the WYSIWYG HTML editors in forms with a Paint > > Here facility, then we make web based tools easier for them. > > > > > > This project aims to develop a finger painting facility. > > > > Implementation idea > > > > * Write a vector-based "paint" facility in JS that runs in the > > browser. * Write a vector or bitmap paint facility in Flash, > > bearing in mind that OLPC ships Gnash instead of Adobe's Flash > > > > Technical notes > > > > * Moodle is using a WYSIWYG editor called TinyMCE - that is a > > possible integration point. > > * Performance matters - the OLPC XO has a relatively low power CPU, > > so image editing has to be tuned / optimised to be > > responsive > > --- end of info > > That info is pretty much all I have too ;-) there is a thread I > started on moodle.org where I asked people to report on nice Flash or > JS based editors, and a few very nice ones emerged. It's nice to play > with the many implementations out there, and see what feels good. > > (I think I posted that link before, don't have it handy atm...) > > > So we have a few questions. > > > > One question is the age category that you have in mind for this > > application. > > 6 to 12 roughly. But "kids of any age" is my target ;-) > > I am already taking the TinyMCE editor and switching off most options. > A very simple editor is enough (brush size, color, eraser). A > sophisticated editor can be a bonus, but it's only interesting the > main goal is that the "core" functionality works really well. > > In other words, if there are more buttons, we might hide them as we do > with tinymce. > > Another aspect of 'sophistication' -- after looking at many editors, > the most valuable feature I've seen is the "replay" button, way more > important than anything else. (see the thread in moodle.org about the > editors ;-) ) > > > Another question is about how you see the further integration with Moodle > > and potentially with TinyMCE. > > - If it is possible to integrate it into TinyMCE itself it might be a > good idea -- means that it canbe reused by any other webapp using > TinyMCE :-) > > - I _think_ that TinyMCE is relatively modular. If this can "plugin" > into tinyMCE, great so moodle can ship a "standard" TinyMCE with a > plugni, rather than a patched TinyMCE. This may well be impossible > though :-/ > > > How would you see a typical use case or > > user-interaction? Would the school server for example show an assignment > > like 'paint a tree' and then the child would paint the tree and submit it > > back to the server for review by the teacher? > > Yes. Or propose "paint something" in a moodle forum which is more fun > and educational than an assignment. > > My example "use cases" and notes... > > - I want to use moodle's forum and "just paint" instead of writing each > post. > > - As a teacher, when I hit 'edit' to edit the texts in the course > outline page (technically called "labels" in moodle code), I want to > be able to paint. > > - Nice workflow fo
Re: [Server-devel] Apache proxy CRCsync
Hi Toby, I did not have much time last week to work on the project but want to continue again this week. I have been thinking about the integration between the standard cache module of apache and the crccache_client cache-handler module. At this moment, the cache module unfortunately does not invoke crccache_client for most dynamic pages; the web/application servers indicate that those pages are not cacheable, either by setting an expiry time in the past or by setting appropriate cache-control headers or a combination of the two. And the cache module respects that, as a good http-citizen. But the whole idea of crccache is that those pages should be stored by crccache_client anyway but get refetched and then delta'd by the crccache_client/crccache_server chain on the next request. So one way or another crccache_client/crccache_server should trick the cache module into caching those dynamic pages. I see two potential ways to make this happen: Option 1) crccache_client (or crccache_server?) modifies the cache related response headers before returning the response back to the cache module. It would modify the headers in such a way that the cache module would decide that the page must be cached but revalidated at the next request. This would require no modifications to the cache module but I do consider it a not-so-clean hack, because we would have to reverse engineer the cache module to understand when to modify the headers and when not to modify the headers. Which is obviously fragile because future enhancements to the cache module could potentially break such logic. Option 2) We introduce some new header(s) that crccache can inject in the response to indicate to the cache module that the pages will be cached by a delta/crcsync aware cache handler. And then we adapt the cache module itself to understand this new header and to cache normally-not-cachable pages if this header is present (and send them for revalidation to the crccache handler upon next request). I see this as a cleaner solution. Though, before immediately starting to implement this solution, I believe that it should be analysed into a little bit more detail. Especially with respect to the future, when crccache will talk to some servers that are crcsync aware and can directly handle the encoding themselves while crccache will at the same time also still talk to many current-gen servers that do not know this http extension. What are your thoughts on this subject? Thanks and kind regards, Alex Op maandag 16 maart 2009, schreef Toby Collett: > Great to hear you got it running, unfortunately I only have about a two > week head start on you with regard to the apache front, so I am sure lots > of things will get neater as we go along. > > 2009/3/16 Alex Wulms > > > Hi Toby, > > > > I managed to get it working on my PC under suse 11.1 with apache 2.2.10. > > > > When I configured a dedicated debug log per virtual server, I noticed > > that the > > crccache_client and crccache_server modules were both invoked in both > > virtual > > servers. Judging from the error log you sent me, that is also the case on > > your server. > > > > I have made following changes to fix the situation: > > > > 1) Move the 'CacheEnable crccache_client' directive (for the 'default' > > virtual > > server) inside the tag. Apparently it is applied globally > > as long as it is outside the tag, regardless of the config > > file in > > which it appears. > > Seems like a sensible change. > > > 2) Introduce a new directive 'CRCCacheServer on'. > > This directive is checked by mod_crccache_server in the > > crccache_server_header_parser_handler. > > It is specified in the tag of the upstream_proxy of the > > virtual > > server. > > Apparently modules get loaded globally and functions like > > the ..._header_parser_handler get invoked for each virtual server, so > > they must check themselves if they should be enabled or disabled in a > > given virtual server. I found this through google, which pointed me to a > > forum where somebody else had faced a similar problem. > > Makes sense > > > I also realize why I only found cached files > > under /var/cache/apache2/mod_crccache_server and not under ..._client. > > It is because the crccache_client.conf and crccache_server.conf file both > > use > > the parameter CacheRoot to store the cache directory. These parameters > > are apparently also global. The fact that they are in two different > > config files > > does not automagically store them in a module specific namespace. So I > > have renamed the parameters to differentiate between the client and the > > server module. > > Actu
Re: [Server-devel] Apache proxy CRCsync
Hi Toby, I managed to get it working on my PC under suse 11.1 with apache 2.2.10. When I configured a dedicated debug log per virtual server, I noticed that the crccache_client and crccache_server modules were both invoked in both virtual servers. Judging from the error log you sent me, that is also the case on your server. I have made following changes to fix the situation: 1) Move the 'CacheEnable crccache_client' directive (for the 'default' virtual server) inside the tag. Apparently it is applied globally as long as it is outside the tag, regardless of the config file in which it appears. 2) Introduce a new directive 'CRCCacheServer on'. This directive is checked by mod_crccache_server in the crccache_server_header_parser_handler. It is specified in the tag of the upstream_proxy of the virtual server. Apparently modules get loaded globally and functions like the ..._header_parser_handler get invoked for each virtual server, so they must check themselves if they should be enabled or disabled in a given virtual server. I found this through google, which pointed me to a forum where somebody else had faced a similar problem. I also realize why I only found cached files under /var/cache/apache2/mod_crccache_server and not under ..._client. It is because the crccache_client.conf and crccache_server.conf file both use the parameter CacheRoot to store the cache directory. These parameters are apparently also global. The fact that they are in two different config files does not automagically store them in a module specific namespace. So I have renamed the parameters to differentiate between the client and the server module. I have also noticed that, although the server module reads these parameters, they actually don't get used by the current code. Are they there due to copy&paste reasons or are they already there for future enhancements, in order to cache stuff temporary on the server side? I have pushed my changes to the repository. Please review them. I'm still new to Apache development so I might have misinterpreted some things. Thanks and kind regards, Alex Op zondag 15 maart 2009, schreef Toby Collett: > Not much time to work on crcsync this weekend, but I have enabled block > replacement, so in theory the latest version in git should be able to be > used to serve web pages. > > Toby ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
