Hey there, it's been a little while since our last announcement, and in case you haven't noticed, we've been a little
too quiet ever since the new year. This silence has been mainly because we've had our heads buried in code! This blog will share with you some of the exciting new changes we're working on inside the BrowserPlus platform, that you can expect to see released in the next couple months. So let's jump in, what's coming?
1. New tools for service developers When developing services, it would be cool if we reduce the develop/test cycle and make it easy to instantly validate and run the service you're working on, without having to write a line of javascript nor even start up your browser. Imagine, this would allow you to write automated tests in a shell script. Well, now you can, meet the "ServiceRunner" program:
CODE
[lloydh@LloydBookPro bpsdk] $ bin/ServiceRunner samples/RubyService
service initialized: HelloRuby v1.0.0
> help
Available commands:
allocate [0 args]: Allocate a new service instance....
describe [0 args]: Extract and display the API description of the ser...
destroy [1 arg]: Destroy a service instance, the single required pa...
help [0-1 args]: Displays command usage. help <command> gives more...
invoke [1-2 args]: Invoke a function on a service instance. First ar...
prompts [0 args]: Show the outstanding user prompts that have been s...
quit [0 args]: Quit the program...
respond [1-2 args]: Respond to a prompt from the service. The first a...
select [1 arg]: Select the current instance, this is a numeric id ...
show [0 args]: Show the currently allocated service instances....
> desc
Describing corelet 'HelloRuby', version: 1.0.0
A service that tests callbacks from ruby.
1 function(s) supported:
howdy:
Say "hello" to the world
callback callback
the callback to send a hello message to
> a
allocated: 1
> i howdy
callback argument 1 invoked:
"howdy there, for the 0th time"
callback argument 1 invoked:
"howdy there, for the 1th time"
callback argument 1 invoked:
"howdy there, for the 2th time"
callback argument 1 invoked:
"howdy there, for the 3th time"
callback argument 1 invoked:
"howdy there, for the 4th time"
callback argument 1 invoked:
"howdy there, for the 5th time"
callback argument 1 invoked:
"howdy there, for the 6th time"
callback argument 1 invoked:
"howdy there, for the 7th time"
callback argument 1 invoked:
"howdy there, for the 8th time"
callback argument 1 invoked:
"howdy there, for the 9th time"
callback argument 1 invoked:
"howdy there, for the 10th time"
"Hello world from my great corelet instance!"
>
Service Runner is a self documented console applications that lets you load and interact with a service. Here you can see we load up the sample ruby service from the SDK, get a textual API description (the 'describe' command), and actually invoke (the 'invoke' command) functions on the service.
A couple nice features in ServiceRunner are the live help, and some features which make interactive usage of the tool more pleasant: these include command disambiguation (you can type 'i' or 'inv' instead of 'invoke') and history and editing support (osx only) compliments of libedit (http://thrysoee.dk/editline/).
2. Services Run In Distinct Processes Here we took a page from Google Chromes' book, and listened to the feedback of several smart folks in the community (the guys from Flock most recently suggested this one). All services as of 2.1.15 will run in a temporal spawned process. This architectural change comes with zero api changes, so existing services will continue running. The benefits of this are extensive, and include 100% resource reclamation (when a service shuts down, absolutely all resources used will be released), a much more stable system (if a service crashes, BrowserPlus itself remains running, as does your browser and website), and an easier development experience: Because your services are now in their own process, it's easier to understand behaviors - (performance and
memory usage), and easier to identify bugs (Is that a bug in the platform? In the service?)
This architectural change will allow us to drastically clean up the RubyInterpreter ruby environment in the near future. We'll be able to fix some community reported oddities (like bp_require() instead of just require()), and should allow us to empower ruby service developers to include their own native extensions.
3. Streamlined Installation Experience The number 1 feedback we get is around the fact that BrowserPlus is implemented as native code, and the end user must actually install the software. Folks tend to worry about user experience in software installation, so we're investing deeply in our installers to make them faster and easier to use. So for instance, on OSX users will no longer be required to type their password, and on both platforms the installers will be true 1 click installers, making the initial installation of BrowserPlus faster and easier.
Taking this a step further, end users are usually more interested in the actual features they'll be getting, rather than the ideas behind
the BrowserPlus platform. So this new installer will have a UI completely in HTML, JavaScript, and CSS, that will be skinnable. So
for instance, if you're using BrowserPlus on your site to provide advanced image editing features, you'll be able to easily put a light
skin on the installer to clearly message to your users the value that they get by installing BrowserPlus. We hope that this makes the
experience clearer to end users. This said, there will be some portion of required messaging that we'll request stays in, the end
user license agreement being a key requirement.
4. i18n and L10n - BrowserPlus Should Speak your Language A key goal for our next release is to have the platform ready and simple to translate into new languages. We'll pick a small set of initial languages and translate into those, subsequently we'll seek to expand our coverage as well as soliciting donated translations from the community (you guys!).
5. Closer to Open Source Back in November 2008 we announced that by the middle of this year we'll be open source. What's up with this? How much does it really take?
Well here's the deal, we have been iterating on BrowserPlus for a long time now. In the beginning we leveraged tons of frameworks and tools both internal to Yahoo! and open source. As we move forward, there are benefits to make the whole platform more stand-alone. Some of the internal stuff we use isn't useful to open source, or really adds to the complexity of building the platform.
At present, we've eliminated all frameworks that either are not open source themselves or would add significantly to the complexity of building the platform. There have been benefits in terms of distribution size, performance, repository size, and build times.
So we're quite happy with the progress we've made, and are now much closer to releasing the code. We will definitely keep our commitment to having full code available by the end of the year. In the meantime you can check out a ton of open source BrowserPlus services by searching for projects starting with with 'bp-'. If you're tinkering with services yourselves, we urge you to follow this convention.
So stay tuned, and feel free to ask more questions about these upcoming features on our forums.
till the next,
lloyd
