adamkhrona's comments

This is good: it's totally insecure to pass auth credentials in plain-text URLs.

Same here, as a developer of a cross-platform library, this is the only configuration that works for us. By restricting virtualization of OSX, Apple has effectively forced most developers to use this configuration.

San Francisco (SOMA), CA - Biz Dev Commando - Contract to Hire (awesomium.com)

Live in SF? Got some business sense? Wanna join a startup that's blowing up? Sweet!

We need a business development 'commando' to take charge of our day-to-day sales and business tasks. Typical things you'll be doing include: responding to sales questions, brainstorming new licensing models, spearheading sales negotiations, evangelizing our product, and _whatever else it takes_.

We make 'Awesomium', a tool for embedding the client-side web in other applications. Our mission is to break the web out of its box and into the hands of developers. Our clients include LEGO, Ubisoft, NCSoft, Sony Online Entertainment, Citrix, and Lockheed Martin.

Above all, we're looking for someone eager, smart, and responsible who wants to get into the ground-floor of a startup and make a real difference.

If this sounds like you, please apply at: http://startupers.com/jobs/khrona/12283/biz-dev-commando

Got questions? Email me (I'm the founder and lead developer) at [email protected]

Just to add to this, the "special characters" are "%E2%80%AE" which is the escaped form of the UTF-8 "Right-To-Left Override" control character (which effectively reverses the display of text).

If you try copying the URL to plain-text, you'll see: http://www.kurlak.com/john/%E2%80%AElmth.ecruos

Hey guys, thanks for the interest in our library!

We're actually getting ready to launch a massive update (1.6.2) to Awesomium in a couple days (new tutorials, new SDK, new .NET wrapper, new samples, etc.) Stay tuned. :-)

Hey, main developer of Awesomium here-- allow me to answer your question:

Awesomium 1.6 was designed from the ground up with the following goals in mind:

* Must render to a 32-bit BGRA pixel-buffer (most common image format)

* Must be absolutely windowless (to allow use in any context, 3D or otherwise)

* Must emulate Chrome's sandbox architecture (for security and crash isolation)

* Must support platform-agnostic input

* Must support Flash plugins on all platforms

* Must be flexible and easy to configure

* Must maintain a simple, easy-to-use API

Chromium Embedded Framework (CEF) is largely intended to be used by "embedding chromium browser windows" in your application. That's a key difference-- you're embedding a window inside of your application versus the more versatile pixel-buffer that our RenderBuffer class provides. This makes it nearly impossible to use inside a 3D graphics context or in other situations where embedding a native window handle is not feasible.

Additionally, CEF has a single-process architecture which means it does not scale as effectively nor isolate crashes in the manner that Awesomium or Chrome does (the Flash plugin can crash on a web-page in Awesomium-- as is liable to happen-- and your application will continue to run as normal).

I personally have been working on embedding WebKit, Mozilla Gecko, and similar technologies for nearly five years now so I've got a pretty good deal of experience on how to do it right. If you need any help, feel free to drop me at line at [email protected]

Indeed-- there's a lot of demand for this kind of component in .NET (especially considering the limitations of the built in WebBrowser class).

Our .NET wrapper is open-source and up on GitHub: https://github.com/khrona/AwesomiumSharp

Btw, AwesomiumSharp has recently been re-written and now includes a drop-in WebControl component for WPF that you can hook up to your application with XAML. We're about to stage a major re-launch of the wrapper + new 1.6.2 SDK release in a couple days.

I'm the main Awesomium developer-- the 1.6 branch is based off a stable revision from April 2010.

We've recently updated to the latest Chromium trunk and will be launching an experimental, public build of our 1.7 branch soon. (Would have happened sooner but we've been focusing more on getting the library stable rather than absorbing new features.)

By the way, we do participate in the development of Chromium (albeit, rather covertly in IRC), I personally have been a long-time lurker of the mailing-list since the first month it opened. :-)

Regarding WebKit's (or, more specifically, WebCore's) LGPL license-- we've sought legal counsel on this and believe we've satisfied the conditions. We are, nonetheless, planning to package up WebKit into a separate dynamic library in the near future.

Not exactly-- awesomium can be used for both headless rendering and embedded GUI rendering. It outputs to a BGRA 32-bit pixel-buffer; it's the embedder's job to display it in their respective UI framework.

Can't beat the Apple Cinema Display 27 inch (or if you're a PC guy, the Dell UltraSharp 27 inch). Got two of them, love them, would never go back.

Thank you for the suggestions, I'll work on making the site more clear to a technical audience.

Our first draft of the site was actually very heavy on the tech details but we ended up trying to dumb it down a bit to appeal to a wider audience. It's tough trying to find a good balance between the two.

We did indeed use Chromium as a base but have implemented a great deal of extra modifications on top to make this the ideal solution for offscreen embedding. Significant portions of the renderer, plugin containers, and Javascript system had to be re-written.

We're working on a Linux port for use server-side but that's not to say our current framework is not headless. We developed this branch to be completely independent of any windowing systems (and have even coaxed Flash and Silverlight to render correctly in such an environment)-- check out our HelloAwesomium sample in the SDK, it runs straight from the command-line and outputs a JPEG.

We created a genuinely windowless branch of Chromium two years ago named Awesomium; it's free for non-commercial use and is used in several major games and commercial projects: http://www.awesomium.com

Chrome was designed to be as simple and easy-to-use as possible; part of this initiative involved being immediately compatible with most corporate set-ups (eg, IE users on a company intranet) so a decision was made to use Windows' proxy configuration settings out of the box.

You can actually override the proxy settings yourself via command line switches, however-- look through this page and search for "proxy": http://peter.sh/experiments/chromium-command-line-switches/