<div dir="ltr">On Sat, Oct 11, 2008 at 6:43 PM, Gary C Martin <span dir="ltr"><<a href="mailto:gary@garycmartin.com">gary@garycmartin.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On 12 Oct 2008, at 01:48, Wade Brainerd wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On the bad side, you can't run two Wikipedias because they will try to bind webservers to the same port. Also, if the user removes Browse, Wikipedia will no longer run.<br>
<br>
These issues could best be solved by a sugar-webcontent-activity package which is shipped by default. It would contain the Browse GUI classes plus a template Activity class. It would also provide a base WebServer class that takes care of finding an unused port and binding to localhost. Content bundles could use the template Activity class as is without any Python code, or else could subclass it (and optionally the WebServer class as well).<br>
</blockquote>
<br></div>
I'm sure I'm missing some obvious rainbow security issue here, but as an exercise in putting my foot in my mouth, could the Activity with the imbedded browse view not just access its files directly via file:// perhaps using some magic to give it the activities installed path location?</blockquote>
<div><br>Oh yeah, that works fine! If it's just static content, no need to subclass anything or even start a webserver. The sugar-webcontent-activity Activity class could just be used directly with file:// URLs, the same way Content bundles work now.<br>
<br>The WebServer class is needed in cases where there is something more complex going on. For example with our Wikipedia activity, each page request involves decompressing Wikitext and dynamically rendering it to HTML. There is also a dynamically generated Search page for search queries, etc. Ideally I'd like to see *that* code become part of sugar-webcontent-activity as well so many Wikislice's could be created without duplicating the server code. It should be as simple as selecting your article list somehow, creating an index page and an icon, and running some script to create a brand new Wikislice activity (say Wikislice Sports etc).<br>
<br>Another example of needing the server would be if someone were to write some kind of interactive testbook with builtin quizzes, that remembered your answers in the journal. <br><br>Basically any kind of complex Web app that wants to run locally on the XO as an Activity.<br>
<br>-Wade<br></div></div><br></div>