Re: [sugar] (another) WebKit port of Browse
Hi, We (I) are indeed porting Gears to browse (the main reason being offline Moodle), and I'd like to be informed if the standard browser for the XO changes, so I know what else to port to, but for now, the majority of the work has been done, and the source code allows for integration with a wide variety of browsers (from konquerer and safari, to Opera and IE6) so using a custom browser (as long as its based on XULRunner 1.8 or 1.9) is no problem. There has also been some thought as to whether to make a plugins/extensions capable attachment to browse (for now the plugins seems to work ok) that would be compatible with FF3 extensions... but this has not been decided yet. Documentation on all of this is not only lacking, its non existent on the web too... I'll try to remedy some of this, after the plugin has been implemented... for future projects with similar goals... Kind Regards, David Van Assche On Tue, Jul 8, 2008 at 1:06 AM, Carol Lerche [EMAIL PROTECTED] wrote: The UI seems pretty important to me, but obviously that's a matter of taste. Not everyone likes tabbed browsing. Correct operation of websites that fail with the extant browser. Direct availability of plugins and addons. One example: scrapbook, a superb research tool. Another example Google Gears (according to a recent mail being ported, presumably because the browser is not standard). I am not familiar with the Firefox codebase, and perhaps all these things are directly available so long as the Firefox 3 engine is there, but if so, there desperately needs to be a detailed body of documentation telling how to access these capabilities. On Mon, Jul 7, 2008 at 3:56 PM, Bobby Powers [EMAIL PROTECTED] wrote: 2008/7/7 Carol Lerche [EMAIL PROTECTED]: Client certs can be used for authentication with no changes to a Firefox browser or an Apache server. GTK based as well as web based software to create certs also already exists. What sort of patch are you looking for? I could certainly provide a page running in an apache server to validate a request for and implant a client cert in a Firefox browser. The issue of certificate creation needs a little more discussion, not because it is difficult or requires a lot of new software to execute, but because it is important to be clear about the requirements. When you describe the overhead, do you mean the overhead of creating the certs? Examining them when someone first logs on? I raised this alternative because you said that a bespoke browser was a requirement to have automatic authentication with the school server. To me, the benefits of running a standard browser are so substantial that this trade off should be considered. Can you explain these benefits? Both Gecko and WebKit are standard browser engines. I don't see much to be gained from a UI perspective (which presumably is what you're taking about?) by switching to FF3. Performance is the only compelling reason I see. Bobby On Mon, Jul 7, 2008 at 3:39 PM, Martin Langhoff [EMAIL PROTECTED] wrote: On Mon, Jul 7, 2008 at 7:20 PM, Carol Lerche [EMAIL PROTECTED] wrote: Why does automatic authentication require a custom browser? Client certificates work well for this function in ordinary web applications (assuming a properly configured server). I haven't delved into this deeply yet, but I suspect that, while I am fond of client certs, they won't work - SSL network and CPU overhead and sidestepping PKI madness for server certs. More on this when I get to implement it. Now, anyone who wants to have a strong say on how I am developing this is free to start implementing it ahead of me, and showing me some fantastic patches :-) cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- Frisbeetarianism is the belief that when you die, your soul goes up on the roof and gets stuck -- George Carlin ___ Devel mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/devel -- Frisbeetarianism is the belief that when you die, your soul goes up on the roof and gets stuck -- George Carlin ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] (another) WebKit port of Browse
A couple points: a) SSL overhead being impractical? Come on. You can use SSL on the browser today; there is no perceptible speed difference. I agree that client certs may be impractical, but it won't be because the XO can't handle the computation. b) Many of the customization issues mooted are just as possible to implement using firefox extensions as they are using the current Browse strategy. Even simplified UI is pretty trivial to implement; see http://lifehacker.com/software/firefox/geek-to-live--consolidate-firefoxs-chrome-210542.php for example. The real question to me is whether there are size (memory nand) disadvantages to Firefox. Othewise it's just a practical problem of finding enough resources to implement a Firefox extension to match the current Browse functionality. --scott -- ( http://cscott.net/ ) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] (another) WebKit port of Browse
On Tue, Jul 8, 2008 at 10:37 AM, C. Scott Ananian [EMAIL PROTECTED] wrote: The real question to me is whether there are size (memory nand) disadvantages to Firefox. Othewise it's just a practical problem of finding enough resources to implement a Firefox extension to match the current Browse functionality. As always, the question stands as if OLPC should try to do better than the current software offerings can do for its users, or if we should just use what already exists. I'm more than happy to experiment with WebKit, Firefox, etc I just hope that we make decisions based on actual feedback from our actual users. Also, we should try to think out of the box, instead of panicking and resorting to all-or-nothing final solutions. One example: what if the need underlying the request for tabs in Browse could be better fulfilled by further improving the activity switching operation in Sugar? Regards, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] (another) WebKit port of Browse
Am 08.07.2008 um 06:35 schrieb Mikus Grinbergs: A reference was made to Gears: My point was exactly that it is a plugin. There are other plugins that are educationally useful. Security. I believe that 'Browse' is restricted as to how much it is allowed to modify the operating system itself. Such restrictions would apply to plugins as well. That concept NEEDS to be enforced. It is. [War story: When plugins first became available for Netscape, I installed one. But Netscape started behaving differently from how I had thought I had set it up. I investigated, and found out that under the covers the plugin had CHANGED (without telling me) some Netscape settings to the way *it* wanted them. Got rid of it fast.] My point is that a 'plugin' is typically a binary blob -- the person installing it on his computer has NO IDEA as to what that plugin might surreptitiously be doing under the covers. And with Bitfrost the user does not *have to have an idea*. A browser plugin can *only* do what the browse activity can do. Nothing more - which is in stark contrast to what a plugin on a regular machine can do (namely, everything the user can do). - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] (another) WebKit port of Browse
Sugarizing involves more than just the look and feel of the UI; in addition to Bitfrost considerations--raised by Bert and Mikus--and the collaboration model, there is also Journal/Datastore intergration to consider: the trivial from of Sugarizing does not result in useful Journal entries. So some downstream intervention will be needed in any case. -waltrer ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] (another) WebKit port of Browse
On Tue, Jul 8, 2008 at 5:37 AM, C. Scott Ananian [EMAIL PROTECTED] wrote: a) SSL overhead being impractical? Come on. You can use SSL on the browser today; there is no perceptible speed difference. I agree that client certs may be impractical, but it won't be because the XO can't handle the computation. Scott - please! We need to raise the level of discussion here. SSL overhead on the *network* and on the XS cpu, though Carol rightly points out we don't need to carry that in all the traffic. There is a _ton_ of work on the PKI side, and she's volunteered to work on that though :-) The real question to me is whether there are size The REAL question here is how do we stop this list being armchair quaterbacking, and start fostering coding work. This thread is a bad bad start. Someone has done a TON of work on Browse, and here is a ton of people ready to throw it out hte window based on opinions. That is *stupid*. Consider replacing it when someone comes up with *working code*. Wake me up when someone has working code - the rest is *noise*. cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] (another) WebKit port of Browse
On Mon, Jul 7, 2008 at 8:47 PM, Carol Lerche [EMAIL PROTECTED] wrote: Martin -- You state that ssl at the network layer is significant. The question is when and how much must ssl be used to authenticate with client certs? I believe it only needs to be used during initial authentication and again when properly designed cookies expire. Since each XO only That's a good point. As to the PKI infrastructure, I don't think it is any harder to work this out than any of the other key management issues already in play. Well, it's a ton of work, and if I can take you on your offer of patches... we cannot provide a PKI infrastructure as a significant proportion of schools is disconnected, and we are not keen on imposing a complex school server setup procedure. So, assuming each XS does the classic self-signed-cert creation, what we want to do is to follow the current trust model, which is dead simple: the XO trusts the XS that it is registered to. During the registration, the XO gives the XS its public SSH key. We need to - change the Registration protocol to grab the public part of the self-signed cert, and add an exception to the PKI checks in Browse. The registration stuff is implemented in a tool called idmgr (XS side) and in Sugar profile (XO side). If you looking at idmgr is horrible enough that you want to help me reimplement it, I have further notes on that track ;-) We also need to tackle the protocol change in a reasonably backwards compat manner. - figure out a way to use the existing SSH key that the XO has as the SSL client cert, and to detect it, and match it on the server side. The server-side apache-embedded code we are doing with mod_python handlers, and this is a perfect fit for an authen handler. Counting on your help to break this silly thread with actual working code :-) cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] (another) WebKit port of Browse
Let me summarize where I think we are and/or should go and try to put this into some context: 0) good rendering onto our high resolution screen is very important to us; this is why we went with a Gecko based web browser in the first place. Before we moved to the development builds of gecko/xulrunner, we had terrible issues with many web site's rendering. I don't know whether or not WebKit supports scaling at this date, but it is a question well worth asking. This new version of Gecko etc. are slated for our next release and are in current development builds. What is WebKit's current capability? 1) memory usage is a very high concern to us. The recent work on FF/Gecko's memory consumption and leak plugging (as reported all over the web) is outstanding, and they should be commended for this work. This improvement should be reflected in the current development build. And this has a major impact on our usability. 2) the lack of a certificate UI has hampered our Browse usage primarily in G1G1 developed world situations: this tells me while it is of concern, it's not as high priority as some other issues might be, certainly lower than 0) or 1). This could be satisfied by adding UI to browse, I believe. 3) Sayamindu has made good progress toward swapping out Matchbox in favor of a conventional window manager; once this is complete, we can satisfy 2) at worst, by those who need it installing a standard Firefox; one could go up from there by using a Sugar theme, to XUL chrome modifications of arbitrary ambition; or installing your favorite web browser of choice. This work to replace Matchbox won't make this release, but I expect be planned on thereafter. 4) alternative browsers are always welcome; but, to make it as our default browser, it needs to: - address our rendering concerns for our screen. - have competitive memory performance - provide sharing features for classroom work (note that providing only an unmodified conventional browser won't currently have these facilities). Additional goodness would be to have a single HTML rendering engine for everything, to save flash space, and the certificate UI we're missing. I can also anticipate Javascript performance may become an issue as its use continues to increase. - Jim -- Jim Gettys [EMAIL PROTECTED] One Laptop Per Child ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] (another) WebKit port of Browse
On Tue, Jul 8, 2008 at 1:32 PM, Jim Gettys [EMAIL PROTECTED] wrote: I can also anticipate Javascript performance may become an issue as its use continues to increase. Confirming this - to work with XS-based tools nicely, JS and related tools (gears) support is a must. cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] (another) WebKit port of Browse
Oh, and as Walter points out, journal integration is also important to us, and necessary in any replacement. Sometimes brain is not engaged. If we can build the OLPCfs stuff that Scott has come up with, this will help unmodified apps interoperate with the journal, but I suspect for something like browse, we'd want pretty full integration. - Jim On Tue, 2008-07-08 at 12:32 -0400, Jim Gettys wrote: Let me summarize where I think we are and/or should go and try to put this into some context: 0) good rendering onto our high resolution screen is very important to us; this is why we went with a Gecko based web browser in the first place. Before we moved to the development builds of gecko/xulrunner, we had terrible issues with many web site's rendering. I don't know whether or not WebKit supports scaling at this date, but it is a question well worth asking. This new version of Gecko etc. are slated for our next release and are in current development builds. What is WebKit's current capability? 1) memory usage is a very high concern to us. The recent work on FF/Gecko's memory consumption and leak plugging (as reported all over the web) is outstanding, and they should be commended for this work. This improvement should be reflected in the current development build. And this has a major impact on our usability. 2) the lack of a certificate UI has hampered our Browse usage primarily in G1G1 developed world situations: this tells me while it is of concern, it's not as high priority as some other issues might be, certainly lower than 0) or 1). This could be satisfied by adding UI to browse, I believe. 3) Sayamindu has made good progress toward swapping out Matchbox in favor of a conventional window manager; once this is complete, we can satisfy 2) at worst, by those who need it installing a standard Firefox; one could go up from there by using a Sugar theme, to XUL chrome modifications of arbitrary ambition; or installing your favorite web browser of choice. This work to replace Matchbox won't make this release, but I expect be planned on thereafter. 4) alternative browsers are always welcome; but, to make it as our default browser, it needs to: - address our rendering concerns for our screen. - have competitive memory performance - provide sharing features for classroom work (note that providing only an unmodified conventional browser won't currently have these facilities). Additional goodness would be to have a single HTML rendering engine for everything, to save flash space, and the certificate UI we're missing. I can also anticipate Javascript performance may become an issue as its use continues to increase. - Jim -- Jim Gettys [EMAIL PROTECTED] One Laptop Per Child ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] (another) WebKit port of Browse
On Tue, 2008-07-08 at 00:17 -0400, Mikus Grinbergs wrote: Not everyone likes tabbed browsing. That may be true - but what if the user needs to reference two (or more) separate pages of information. If while looking at one page he can't remember *exactly* what the other page said, he may want to switch between pages. What are the alternatives to tabbed browsing? [To me, it is more logical to select a tab created under my control, than to select from the previously-seen list as presented by the Browse 'Back' button. And to open several instances of the existing Activity seems wasteful.] Patches gratefully accepted. Note that due to memory usage, even tabs have their limits (though it may be the recent improvements in Gecko obviate this problem somewhat; it frees pixmap storage unused in finite time). Note the WebKit I would hope are now similarly motivated (competition is a wonderful thing ;-)). - Jim -- Jim Gettys [EMAIL PROTECTED] One Laptop Per Child ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] (another) WebKit port of Browse
So there are two threads here, the first being authentication and the second whether the standard browser could be used (I am still interested in a user story as to why collaborative browsing is interesting/useful as opposed to a shared bookmark or scrapbook). While I am mostly interested in the second issue personally, I can certainly produce a proof of concept for the first, using client certs via Scott's Firefox 3. I don't think it is as hard as you think, and I promise to provide something concrete by the end of the weekend. As to the PKI infrastructure, I don't think it is any harder to work this out than any of the other key management issues already in play. Well, it's a ton of work, and if I can take you on your offer of patches... we cannot provide a PKI infrastructure as a significant proportion of schools is disconnected, and we are not keen on imposing a complex school server setup procedure. So, assuming each XS does the classic self-signed-cert creation, what we want to do is to follow the current trust model, which is dead simple: the XO trusts the XS that it is registered to. I am puzzled about the PKI infrastructure you envision. I envision having a private certificate authority that runs on the teacher's XO and keeps its keystore on a USB thumb drive. So my favorite CA tool is TinyCA (currently version2) which is written in Perl. This works very well for me, it has a GTK interface and does its PKI using OpenSSL like everyone else. This is what I am going to use and document to create the certs. During the registration, the XO gives the XS its public SSH key. We need to - change the Registration protocol to grab the public part of the self-signed cert, and add an exception to the PKI checks in Browse. The registration stuff is implemented in a tool called idmgr (XS side) and in Sugar profile (XO side). If you looking at idmgr is horrible enough that you want to help me reimplement it, I have further notes on that track ;-) We also need to tackle the protocol change in a reasonably backwards compat manner. Please point me to your notes on this, if you would be so kind. - figure out a way to use the existing SSH key that the XO has as the SSL client cert, and to detect it, and match it on the server side. There are a couple of ways this can work. I will implement this in my POC. The server-side apache-embedded code we are doing with mod_python handlers, and this is a perfect fit for an authen handler. Not promising to do the Apache side in Python for the POC. I write in Perl by choice, so hold your nose. But are you planning to use Apache or lighttpd for the lightweight XS? Counting on your help to break this silly thread with actual working code :-) I'm happy to oblige! At last a project that doesn't require me to create a GUI. Brickbats regarding this plan of action are gratefully accepted. Carol Lerche ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] (another) WebKit port of Browse
On Tue, Jul 8, 2008 at 6:32 PM, Jim Gettys [EMAIL PROTECTED] wrote: 2) the lack of a certificate UI has hampered our Browse usage primarily in G1G1 developed world situations: this tells me while it is of concern, it's not as high priority as some other issues might be, certainly lower than 0) or 1). This could be satisfied by adding UI to browse, I believe. Hi, this has been fixed (by Marco) and is in the joyride builds, we are using now the same mechanism as FF3. We could add many more of the missing features to Browse if all the developers weren't so busy with the rest of Sugar. Also, although most of the sugar developers have occasionally hacked on Browse, we are far from experts in the big piece of code that Mozilla is. In my opinion, if Browse is so important for OLPC, the following should happen: - discover what the actual users (kids and teachers) need and is not yet present in Browse, - discover what the sales team need in Browse to successfully market the whole OLPC stuff (firefox brand?), - contract any of the people with actual experience in the internals of mozilla for cooperating with the current Sugar developers in order to bring those new features. I know that hiring takes time, I'm just making the point that doing the Browse activity we want for OLPC is not anything impossible nor a gigantic task. But requires at least focused people and efforts, and better if those people already have the right experience. Regards, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] (another) WebKit port of Browse
On Tue, Jul 8, 2008 at 1:32 PM, Tomeu Vizoso [EMAIL PROTECTED] wrote: We could add many more of the missing features to Browse if all the developers weren't so busy with the rest of Sugar. Also, although most of the sugar developers have occasionally hacked on Browse, we are far from experts in the big piece of code that Mozilla is. This was my original point. We either have sufficient resources to develop our own browser, or we don't. I think it will (in the end) be more efficient to develop small Firefox extensions to support Journal integration and collaboration, rather than taxing the sugar developers with an attempt to (basically) reimplement large parts of firefox. I know that hiring takes time, I'm just making the point that doing the Browse activity we want for OLPC is not anything impossible nor a gigantic task. But requires at least focused people and efforts, and better if those people already have the right experience. And my basic point was that I thought we'd be better off leveraging more of the upstream feature development directly, so that our Browse would continue to improve w/o our hiring a full time Browse developer. Anyway, as Martin says, this is all armchair quarterbacking until someone gets Firefox to more-or-less the same level as Browse is now. In my earlier part I started the process by packing Firefox 3.0 as a self-contained .xo file (no yum required); the next steps are to install the appropriate theme tweaks to integrate it into the sugar look, possibly some libsugarization, and to write the extensions to integrate with Tubes and the datastore (XUL is your friend). --scott -- ( http://cscott.net/ ) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] (another) WebKit port of Browse
On Tue, Jul 8, 2008 at 2:27 PM, Carol Lerche [EMAIL PROTECTED] wrote: I can certainly produce a proof of concept for the first, using client certs via Scott's Firefox 3. I don't think it is as hard as you think, and I promise to provide something concrete by the end of the weekend. Thanks! [ but do see my note at the end ] I am puzzled about the PKI infrastructure you envision. I envision having a private certificate authority that runs on the teacher's XO and keeps its keystore on a USB thumb drive. So my favorite CA tool is TinyCA (currently version2) which is written in Perl. This works very well for me, it has a GTK interface and does its PKI using OpenSSL like everyone else. This is what I am going to use and document to create the certs. That seems to require a fairly complex setup, and is vulnerable to losing the usb drive. - change the Registration protocol to grab the public part of the ... Please point me to your notes on this, if you would be so kind. There aren't any, unfortunately. I had to read idmgr to understand the protocol - so read the source. It is a trivial xml-rpc. - figure out a way to use the existing SSH key that the XO has as the SSL client cert, and to detect it, and match it on the server side. There are a couple of ways this can work. I will implement this in my POC. Cool. The server-side apache-embedded code we are doing with mod_python handlers, and this is a perfect fit for an authen handler. Not promising to do the Apache side in Python for the POC. I write in Perl by choice, so hold your nose. But are you planning to use Apache or lighttpd for the lightweight XS? I am a happy Perl hacker in Python land too, and I finding that mod_python hacking is similar to mod_perl hacking. Anyway, if you can sort out the rest, I can probably deal with the mod_python bit :-) And yes - using apache so far. Counting on your help to break this silly thread with actual working code :-) I'm happy to oblige! At last a project that doesn't require me to create a GUI. Brickbats regarding this plan of action are gratefully accepted. Note: The only thing that saddens me is that basing it on FF turns your help into more of a political wedge than technical help. The two issues (auth, browser) are orthogonal. Short term, we need the authentication stuff. Scott's mumblings are about future scenarios, and are missing a lot of aspects - see jg's post. In the best of cases, it is a medium-term thing. And it is odd timing to be talking about ah, let's change the browser when everyone tries to focus on 8.2.0. For example, if you do it on Browse instead of FF, and it is a neat patch, we could argue for inclusion in a minor update (say, 8.2.1) as it enables proper operation of the restore part of backup :-) And that means proper backup/restore is in the hands of thousands of kids many MANY moons earlier. Just to put the jockeying in perspective. m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] (another) WebKit port of Browse
On Tue, Jul 8, 2008 at 8:05 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: On Tue, Jul 8, 2008 at 1:32 PM, Tomeu Vizoso [EMAIL PROTECTED] wrote: We could add many more of the missing features to Browse if all the developers weren't so busy with the rest of Sugar. Also, although most of the sugar developers have occasionally hacked on Browse, we are far from experts in the big piece of code that Mozilla is. This was my original point. We either have sufficient resources to develop our own browser, or we don't. I think it will (in the end) be more efficient to develop small Firefox extensions to support Journal integration and collaboration, rather than taxing the sugar developers with an attempt to (basically) reimplement large parts of firefox. Well, the same could be said about the rest of Sugar. If our users are better served by standard linux desktop components progressively improved for our learning goals, we should drop Sugar and go for that. I know that hiring takes time, I'm just making the point that doing the Browse activity we want for OLPC is not anything impossible nor a gigantic task. But requires at least focused people and efforts, and better if those people already have the right experience. And my basic point was that I thought we'd be better off leveraging more of the upstream feature development directly, so that our Browse would continue to improve w/o our hiring a full time Browse developer. Same as above, if OLPC's strategy is to be that, I should be working on Nautilus instead of the Journal. Again, I would like to see a list of the features actually needed by users and sales, and then revisit the decision of how OLPC should be spending its resources. In the meantime, all the testing with kids that could be done with different browsers would be very useful. Anyway, as Martin says, this is all armchair quarterbacking until someone gets Firefox to more-or-less the same level as Browse is now. In my earlier part I started the process by packing Firefox 3.0 as a self-contained .xo file (no yum required); the next steps are to install the appropriate theme tweaks to integrate it into the sugar look, possibly some libsugarization, and to write the extensions to integrate with Tubes and the datastore (XUL is your friend). Sure, all this will be very interesting work regardless of which browser each deployment chooses to deploy. Regards, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] (another) WebKit port of Browse
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 C. Scott Ananian wrote: | On Tue, Jul 8, 2008 at 1:32 PM, Tomeu Vizoso [EMAIL PROTECTED] wrote: | We could add many more of the missing features to Browse if all the | developers weren't so busy with the rest of Sugar. Also, although most | of the sugar developers have occasionally hacked on Browse, we are far | from experts in the big piece of code that Mozilla is. | | This was my original point. We either have sufficient resources to | develop our own browser, or we don't. I think it will (in the end) be | more efficient to develop small Firefox extensions to support Journal | integration and collaboration, rather than taxing the sugar developers | with an attempt to (basically) reimplement large parts of firefox. I disagree. I expect that these two options will require a very similar amount of code... but one of them is already largely complete (if beta), while the other is hypothetical. Browse a custom UI on XULRunner, with brand-new code for sharing and datastore access. Moving that code into extensions doesn't reduce the amount of code. Neither of these scenarios is more our own browser than the other. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhzsIgACgkQUJT6e6HFtqRclQCfRSZXm2NgTztwVMnXMhcW4LEL CAEAoIj2t4FVX0PRqcjdAVm0PYLLHVl3 =crMM -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] (another) WebKit port of Browse
On Tue, Jul 8, 2008 at 8:23 PM, Benjamin M. Schwartz [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 C. Scott Ananian wrote: | On Tue, Jul 8, 2008 at 1:32 PM, Tomeu Vizoso [EMAIL PROTECTED] wrote: | We could add many more of the missing features to Browse if all the | developers weren't so busy with the rest of Sugar. Also, although most | of the sugar developers have occasionally hacked on Browse, we are far | from experts in the big piece of code that Mozilla is. | | This was my original point. We either have sufficient resources to | develop our own browser, or we don't. I think it will (in the end) be | more efficient to develop small Firefox extensions to support Journal | integration and collaboration, rather than taxing the sugar developers | with an attempt to (basically) reimplement large parts of firefox. I disagree. I expect that these two options will require a very similar amount of code... but one of them is already largely complete (if beta), while the other is hypothetical. Browse a custom UI on XULRunner, with brand-new code for sharing and datastore access. Moving that code into extensions doesn't reduce the amount of code. Neither of these scenarios is more our own browser than the other. Adding to Ben's comments, I would like to remember that by embedding a browser widget (mozilla or webkit) inside a python activity we are giving great opportunities to hack around it, either in derivatives of Browse or in new activities. If we just added a number of extensions to Firefox either in C++ or JS, could we deliver as much to the kids that want to study and modify the software on their machines? Regards, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] (another) WebKit port of Browse
On Tue, Jul 8, 2008 at 1:03 PM, Jim Gettys [EMAIL PROTECTED] wrote: On Tue, 2008-07-08 at 00:17 -0400, Mikus Grinbergs wrote: Not everyone likes tabbed browsing. That may be true - but what if the user needs to reference two (or more) separate pages of information. If while looking at one page he can't remember *exactly* what the other page said, he may want to switch between pages. What are the alternatives to tabbed browsing? [To me, it is more logical to select a tab created under my control, than to select from the previously-seen list as presented by the Browse 'Back' button. And to open several instances of the existing Activity seems wasteful.] Patches gratefully accepted. Note that due to memory usage, even tabs have their limits (though it may be the recent improvements in Gecko obviate this problem somewhat; it frees pixmap storage unused in finite time). Note the WebKit I would hope are now similarly motivated (competition is a wonderful thing ;-)). - Jim I updated the WebKit Browse to use the latest GIT WebKit, merge in the latest mainline changes in Browse, and do fullpage zoom. http://dev.laptop.org/~bobbyp/Browse-93.xo Bobby (I've been watching youtube videos in WebKit/Browse a day. its a little choppy, but thats probably gstreamer/ffmpeg) -- Jim Gettys [EMAIL PROTECTED] One Laptop Per Child ___ Devel mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/devel ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] (another) WebKit port of Browse
On Tue, Jul 8, 2008 at 2:34 PM, Tomeu Vizoso [EMAIL PROTECTED] wrote: If we just added a number of extensions to Firefox either in C++ or JS, could we deliver as much to the kids that want to study and modify the software on their machines? Yes. Firefox has a much better integrated IDE for XUL/JS work than we have for Python. --scott -- ( http://cscott.net/ ) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] (another) WebKit port of Browse
On Tue, Jul 8, 2008 at 8:59 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: On Tue, Jul 8, 2008 at 2:34 PM, Tomeu Vizoso [EMAIL PROTECTED] wrote: If we just added a number of extensions to Firefox either in C++ or JS, could we deliver as much to the kids that want to study and modify the software on their machines? Yes. Firefox has a much better integrated IDE for XUL/JS work than we have for Python. Cool, and can you call any c library in the system like you can with python's ctypes? Or are you restricted to either JS files and XPCOM or C++? Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] (another) WebKit port of Browse
On Tue, Jul 8, 2008 at 3:07 PM, Martin Langhoff [EMAIL PROTECTED] wrote: Please point me to your notes on this, if you would be so kind. There aren't any, unfortunately. I had to read idmgr to understand the protocol - so read the source. It is a trivial xml-rpc. Ah, apologies, wrong answer. I do have some mental notes, but you might want to read idmgr before getting both of us into such trouble :-) cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] (another) WebKit port of Browse
Hi Folks, I spent a couple hours yesterday taking out Gecko from Browse, and putting in WebKit. Luckily, this was made easy by some PyWebKitGtk bindings from Jan Alonzo (cc'ed). The example included with the bindings is actually based off WebKit ;). Some initial documentation is here: http://wiki.laptop.org/go/Browse/WebKit things work pretty well in general, but gmail chokes, possibly due to gnash. if you just want to try it (on an F9 based joyride), the bundle is: http://dev.laptop.org/~bobbyp/Browse-92.xo yours, Bobby Powers Intern Extroadinare (irc: nteon) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] (another) WebKit port of Browse
On Mon, Jul 7, 2008 at 12:39 PM, Bobby Powers [EMAIL PROTECTED] wrote: I spent a couple hours yesterday taking out Gecko from Browse, and putting in WebKit. Luckily, this was made easy by some PyWebKitGtk Just repeating in public what I leaned over and told m_stone and cjb: I'd rather see us just give up on Browse and ship and appropriately configured Firefox. I just can't see OLPC devoting enough developer resources long-term to maintain a competitive browser. I understand that the major benefit of WebKit is speed and (memory, NAND) size. I'd like to see a quantitative comparison against both our current gecko-based browser and against firefox, so that we can make a more informed decision re: whether it is still to our benefit to ship a bespoke browser. --scott (mstone reports that 'yum install firefox' and 'firefox' is a decent basis for comparison, although we can tweak firefox's configuration and package it as an RPM to get a nicer sugar lookfeel if we really wanted to pursue this route.) -- ( http://cscott.net/ ) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] (another) WebKit port of Browse
Why does automatic authentication require a custom browser? Client certificates work well for this function in ordinary web applications (assuming a properly configured server). As to collaborative browsing, that use case should be balanced against all the available applications that having a standard Firefox enables painlessly. Where is a user story of collaborative browsing (as contrasted to a shared bookmark repository) documented? On Mon, Jul 7, 2008 at 3:10 PM, Martin Langhoff [EMAIL PROTECTED] wrote: On Mon, Jul 7, 2008 at 6:56 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: I'd rather see us just give up on Browse and ship and appropriately configured Firefox. I just can't see OLPC devoting enough developer Not so fast! The XS deliverables need a custom browser on the XO for reasons we were discussing last Thursday :-) If we want - automagic authentication with the XS - collaborative browsing (which can get better than what we have) we need a custom, bespoke, forked, evil, lasers-on-sharkies-heads browser. Call it Betty if you want, but we need it. m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/devel -- Frisbeetarianism is the belief that when you die, your soul goes up on the roof and gets stuck -- George Carlin ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] (another) WebKit port of Browse
Client certs can be used for authentication with no changes to a Firefox browser or an Apache server. GTK based as well as web based software to create certs also already exists. What sort of patch are you looking for? I could certainly provide a page running in an apache server to validate a request for and implant a client cert in a Firefox browser. The issue of certificate creation needs a little more discussion, not because it is difficult or requires a lot of new software to execute, but because it is important to be clear about the requirements. When you describe the overhead, do you mean the overhead of creating the certs? Examining them when someone first logs on? I raised this alternative because you said that a bespoke browser was a requirement to have automatic authentication with the school server. To me, the benefits of running a standard browser are so substantial that this trade off should be considered. On Mon, Jul 7, 2008 at 3:39 PM, Martin Langhoff [EMAIL PROTECTED] wrote: On Mon, Jul 7, 2008 at 7:20 PM, Carol Lerche [EMAIL PROTECTED] wrote: Why does automatic authentication require a custom browser? Client certificates work well for this function in ordinary web applications (assuming a properly configured server). I haven't delved into this deeply yet, but I suspect that, while I am fond of client certs, they won't work - SSL network and CPU overhead and sidestepping PKI madness for server certs. More on this when I get to implement it. Now, anyone who wants to have a strong say on how I am developing this is free to start implementing it ahead of me, and showing me some fantastic patches :-) cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- Frisbeetarianism is the belief that when you die, your soul goes up on the roof and gets stuck -- George Carlin ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] (another) WebKit port of Browse
The UI seems pretty important to me, but obviously that's a matter of taste. Not everyone likes tabbed browsing. Correct operation of websites that fail with the extant browser. Direct availability of plugins and addons. One example: scrapbook, a superb research tool. Another example Google Gears (according to a recent mail being ported, presumably because the browser is not standard). I am not familiar with the Firefox codebase, and perhaps all these things are directly available so long as the Firefox 3 engine is there, but if so, there desperately needs to be a detailed body of documentation telling how to access these capabilities. On Mon, Jul 7, 2008 at 3:56 PM, Bobby Powers [EMAIL PROTECTED] wrote: 2008/7/7 Carol Lerche [EMAIL PROTECTED]: Client certs can be used for authentication with no changes to a Firefox browser or an Apache server. GTK based as well as web based software to create certs also already exists. What sort of patch are you looking for? I could certainly provide a page running in an apache server to validate a request for and implant a client cert in a Firefox browser. The issue of certificate creation needs a little more discussion, not because it is difficult or requires a lot of new software to execute, but because it is important to be clear about the requirements. When you describe the overhead, do you mean the overhead of creating the certs? Examining them when someone first logs on? I raised this alternative because you said that a bespoke browser was a requirement to have automatic authentication with the school server. To me, the benefits of running a standard browser are so substantial that this trade off should be considered. Can you explain these benefits? Both Gecko and WebKit are standard browser engines. I don't see much to be gained from a UI perspective (which presumably is what you're taking about?) by switching to FF3. Performance is the only compelling reason I see. Bobby On Mon, Jul 7, 2008 at 3:39 PM, Martin Langhoff [EMAIL PROTECTED] wrote: On Mon, Jul 7, 2008 at 7:20 PM, Carol Lerche [EMAIL PROTECTED] wrote: Why does automatic authentication require a custom browser? Client certificates work well for this function in ordinary web applications (assuming a properly configured server). I haven't delved into this deeply yet, but I suspect that, while I am fond of client certs, they won't work - SSL network and CPU overhead and sidestepping PKI madness for server certs. More on this when I get to implement it. Now, anyone who wants to have a strong say on how I am developing this is free to start implementing it ahead of me, and showing me some fantastic patches :-) cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- Frisbeetarianism is the belief that when you die, your soul goes up on the roof and gets stuck -- George Carlin ___ Devel mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/devel -- Frisbeetarianism is the belief that when you die, your soul goes up on the roof and gets stuck -- George Carlin ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] (another) WebKit port of Browse
Carol, give me some credit :-) I know that FF works well with client certs and apache has no problem with it. I've been coding apache/ssl aware apps since '98... What sort of patch are you looking for? Well, there is quite a bit of thinking that needs to happen here, and I am working on something else at the moment. So, these are quick notes - XS installs/deployments will be done in so many different scenarios that we cannot address the promises needed the conventional PKI infrastructure. We need a good strategy to sidestep the PKI requirements of full blown SSL. A few weird schemes come to mind, all nasty :-) - SSL overhead at the network layer is very significant. Network bandwidth and latency on the local link are valuable resources. - SSL CPU overhead at the XS end is moderately significant. And then there is the huge work to chop the Firefox interface into something that fits our UI guidelines (and our screen) - I don't claim to know about that part, but you can imagine that *that* part of the problem is enough to make wise hackers declare that maintaining Browse for the long term is Just Fine. cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] (another) WebKit port of Browse
On Mon, Jul 7, 2008 at 7:06 PM, Carol Lerche [EMAIL PROTECTED] wrote: The UI seems pretty important to me, but obviously that's a matter of taste. Not everyone likes tabbed browsing. Correct operation of websites that fail with the extant browser. Direct availability of plugins and addons. One example: scrapbook, a superb research tool. Another example Google Gears (according to a recent mail being ported, presumably because the browser is not standard). I am not familiar with the Firefox codebase, and perhaps all these things are directly available so long as the Firefox 3 engine is there, but if so, there desperately needs to be a detailed body of documentation telling how to access these capabilities. Carol - I created a page on the wiki to list these problem sites. Can you please record these sites there? http://wiki.laptop.org/go/Browse/ProblemSites And, to be fair, Gears is not (only) a website, its a browser plug-in that allows you to interact with certain websites offline. (and I do think someone is working on porting it as you said). Bobby On Mon, Jul 7, 2008 at 3:56 PM, Bobby Powers [EMAIL PROTECTED] wrote: 2008/7/7 Carol Lerche [EMAIL PROTECTED]: Client certs can be used for authentication with no changes to a Firefox browser or an Apache server. GTK based as well as web based software to create certs also already exists. What sort of patch are you looking for? I could certainly provide a page running in an apache server to validate a request for and implant a client cert in a Firefox browser. The issue of certificate creation needs a little more discussion, not because it is difficult or requires a lot of new software to execute, but because it is important to be clear about the requirements. When you describe the overhead, do you mean the overhead of creating the certs? Examining them when someone first logs on? I raised this alternative because you said that a bespoke browser was a requirement to have automatic authentication with the school server. To me, the benefits of running a standard browser are so substantial that this trade off should be considered. Can you explain these benefits? Both Gecko and WebKit are standard browser engines. I don't see much to be gained from a UI perspective (which presumably is what you're taking about?) by switching to FF3. Performance is the only compelling reason I see. Bobby On Mon, Jul 7, 2008 at 3:39 PM, Martin Langhoff [EMAIL PROTECTED] wrote: On Mon, Jul 7, 2008 at 7:20 PM, Carol Lerche [EMAIL PROTECTED] wrote: Why does automatic authentication require a custom browser? Client certificates work well for this function in ordinary web applications (assuming a properly configured server). I haven't delved into this deeply yet, but I suspect that, while I am fond of client certs, they won't work - SSL network and CPU overhead and sidestepping PKI madness for server certs. More on this when I get to implement it. Now, anyone who wants to have a strong say on how I am developing this is free to start implementing it ahead of me, and showing me some fantastic patches :-) cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- Frisbeetarianism is the belief that when you die, your soul goes up on the roof and gets stuck -- George Carlin ___ Devel mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/devel -- Frisbeetarianism is the belief that when you die, your soul goes up on the roof and gets stuck -- George Carlin ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] (another) WebKit port of Browse
2008/7/7 Carol Lerche [EMAIL PROTECTED]: The UI seems pretty important to me, but obviously that's a matter of taste. Not everyone likes tabbed browsing. Correct operation of websites that fail with the extant browser. Direct availability of plugins and addons. One example: scrapbook, a superb research tool. Another example Google Gears (according to a recent mail being ported, presumably because the browser is not standard). I am not familiar with the Firefox codebase, and perhaps all these things are directly available so long as the Firefox 3 engine is there, but if so, there desperately needs to be a detailed body of documentation telling how to access these capabilities. I certainly acknowledge that a) the sparse UI isn't for everyone and b) the UI is young and still needs some more work (and more features). It started out bare bones, and is slowly gaining important features as we go (recently URI autocompletion, find in page text, foundational support for global bookmarks, and other features appeared!). It should also be noted that tabs were part of the initial design, and were taken out both to prevent abuse of RAM and because we thought that it might be confused adjacent to the link sharing feature, which we felt was a really important addition for our target audience and collaborative learning. I'd consider adding them in light of recent engine improvements, assuming we can prove that kids navigate them naturally. Additionally, I'd love to see other individuals with interest porting other browsers to the XO. I think someone was working on this with Opera. Perhaps a more full featured Firefox could also be Sugarized. However, we designed the current Browse as is to be purposely sparse, to give kids the basics without overloading them with things that could get in the way. I think there's a place for Browse as a default browser, especially for kids under 8 or so, even if other more complex browsers appear as viable alternatives. - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] (another) WebKit port of Browse
Allowing the null encryption algorithm in the browser would enable it for other later negotiations, which seems an unnecessary exposure to suppress the encryption for a single small https exchange. But it would certainly be possible. On Mon, Jul 7, 2008 at 9:44 PM, [EMAIL PROTECTED] wrote: On Mon, 7 Jul 2008, Martin Langhoff wrote: On Mon, Jul 7, 2008 at 7:20 PM, Carol Lerche [EMAIL PROTECTED] wrote: Why does automatic authentication require a custom browser? Client certificates work well for this function in ordinary web applications (assuming a properly configured server). I haven't delved into this deeply yet, but I suspect that, while I am fond of client certs, they won't work - SSL network and CPU overhead and sidestepping PKI madness for server certs. More on this when I get to implement it. what about using client certs, but then null encryption after that? it's a non-standard config, but that's just a config option, not code changes. David Lang Now, anyone who wants to have a strong say on how I am developing this is free to start implementing it ahead of me, and showing me some fantastic patches :-) cheers, m -- Frisbeetarianism is the belief that when you die, your soul goes up on the roof and gets stuck -- George Carlin ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] (another) WebKit port of Browse
On Tue, 8 Jul 2008, Mikus Grinbergs wrote: Not everyone likes tabbed browsing. That may be true - but what if the user needs to reference two (or more) separate pages of information. If while looking at one page he can't remember *exactly* what the other page said, he may want to switch between pages. What are the alternatives to tabbed browsing? multiple screens of browsing (currently only available by running multiple copies of browse, with the associated memory useage) David Lang [To me, it is more logical to select a tab created under my control, than to select from the previously-seen list as presented by the Browse 'Back' button. And to open several instances of the existing Activity seems wasteful.] mikus ___ Devel mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/devel ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] (another) WebKit port of Browse
A reference was made to Gears: My point was exactly that it is a plugin. There are other plugins that are educationally useful. Security. I believe that 'Browse' is restricted as to how much it is allowed to modify the operating system itself. Such restrictions would apply to plugins as well. That concept NEEDS to be enforced. [War story: When plugins first became available for Netscape, I installed one. But Netscape started behaving differently from how I had thought I had set it up. I investigated, and found out that under the covers the plugin had CHANGED (without telling me) some Netscape settings to the way *it* wanted them. Got rid of it fast.] My point is that a 'plugin' is typically a binary blob -- the person installing it on his computer has NO IDEA as to what that plugin might surreptitiously be doing under the covers. mikus ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] (another) WebKit port of Browse
I've snipped away the parts I have no comment on, but: On Mon, 7 Jul 2008, Martin Langhoff wrote: Well, there is quite a bit of thinking that needs to happen here, and I am working on something else at the moment. So, these are quick notes And me, too - just quick notes: - XS installs/deployments will be done in so many different scenarios that we cannot address the promises needed the conventional PKI infrastructure. We need a good strategy to sidestep the PKI requirements of full blown SSL. A few weird schemes come to mind, all nasty :-) I'd be interested to hear them. - SSL overhead at the network layer is very significant. Network bandwidth and latency on the local link are valuable resources. Do it once at authentication time and use an HTTP cookie after that (that is available to HTTP sites in the same doamin). - SSL CPU overhead at the XS end is moderately significant. Same answer as above. -- Asheesh. -- Life is a grand adventure -- or it is nothing. -- Helen Keller ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
