Shakhar
Mike Stay
The name is Hebrew for the color of the sky just before dawn; it also
puns on the SR-71 Blackbird and its replacement, the SR-91 Aurora,
both of which are planes that "fly above the cloud".
The idea is to run Javascript code both on the client and on an App
Engine server to form una. An unum will provide javascript code to
instantiate a local presence in the browser; that code will be cajoled
and endowed with authority by the user. We'll use Kevin Reid's
Caja-CapTP for the internal protocol. An unum can also be serialized
and persisted in the App Engine datastore. We'll use web-keys for
remote references. We intend to implement a CapDesk-like environment
for the UI. Existing web apps can be tamed and exposed as una; one
might provide the OpenSocial API as an unum.
The hope is that by following this route, we can make a web platform
that is entirely based on POLA and ocaps, allowing secure mash-ups of
any web content, simply by sharing web-keys.
All of the pieces have been implemented: Caja, App Engine, Rhino,
Caja-CapTP, YUI, etc; it remains to wire them all together into
something that can show others what a good web platform can do.
There's plenty to do, and we encourage contributions.
If you didn't understand one or more of the terms, here's a glossary
on the project's site (currently the only content there):
http://code.google.com/p/google-caja-shakhar/wiki/ShakharIntroduction
--
Mike Stay - meta...@gmail.com
http://math.ucr.edu/~mike
http://reperiendi.wordpress.com
Mike Stay
> Ihab Awad and I have started a sub-project of Caja called "Shakhar".
> The name is Hebrew for the color of the sky just before dawn
It was pointed out that the proper orthography for the Hebrew word
just uses h, not kh. So I've moved the project to
http://code.google.com/p/google-caja-shahar
Kris Kowal
> The name is Hebrew for the color of the sky just before dawn; it also
> puns on the SR-71 Blackbird and its replacement, the SR-91 Aurora,
> both of which are planes that "fly above the cloud".
I knew a guy named Shahar; it's a pleasure to now know the etymology.
If it's of any consequence or use, several folks, including me, have
managed to deploy Narwhal applications with modules as Ihab and I
described them in January on Google App Engine. I'm presently
focusing on creating a myriad of browser deployment solutions (inline
script, script injection, xhr) x (blocking, async) x (bundled,
individual) x (with cache induction, without). I think it would be a
big win if we could get portions of these projects packaged for
Narwhal. Narwhal comes with "virtualenv" support, a package
installer, and a JSON command line tool out of the box, so it's very
developer friendly, and if the secure server side components have a
module loader that supports the module spec, we could use some modules
on both the server and the client. I'm shooting for a Wiki proof of
concept using one of our two markup language packages that have been
ported so far (wiky or markdown; I presume the former since the latter
does not protect against script injection).
Kris
Mike Stay
>
> On Mon, Jul 27, 2009 at 2:23 PM, Mike Stay<meta...@gmail.com> wrote:
>> Ihab Awad and I have started a sub-project of Caja called "Shakhar".
>> The name is Hebrew for the color of the sky just before dawn; it also
>> puns on the SR-71 Blackbird and its replacement, the SR-91 Aurora,
>> both of which are planes that "fly above the cloud".
>
> I knew a guy named Shahar; it's a pleasure to now know the etymology.
My favorite use of it is in this passage from Isaiah:
[Is] not this the fast that I have chosen? to loose the bands of
wickedness, to undo the heavy burdens, and to let the oppressed go
free, and that ye break every yoke? [Is it] not to deal thy bread to
the hungry, and that thou bring the poor that are cast out to thy
house? when thou seest the naked, that thou cover him; and that thou
hide not thyself from thine own flesh? Then shall thy light break
forth as the morning [shahar], and thine health shall spring forth
speedily: and thy righteousness shall go before thee; the glory of the
LORD shall be thy rearguard.
> If it's of any consequence or use, several folks, including me, have
> managed to deploy Narwhal applications with modules as Ihab and I
> described them in January on Google App Engine. I'm presently
> focusing on creating a myriad of browser deployment solutions (inline
> script, script injection, xhr) x (blocking, async) x (bundled,
> individual) x (with cache induction, without). I think it would be a
> big win if we could get portions of these projects packaged for
> Narwhal. Narwhal comes with "virtualenv" support, a package
> installer, and a JSON command line tool out of the box, so it's very
> developer friendly, and if the secure server side components have a
> module loader that supports the module spec, we could use some modules
> on both the server and the client. I'm shooting for a Wiki proof of
> concept using one of our two markup language packages that have been
> ported so far (wiky or markdown; I presume the former since the latter
> does not protect against script injection).
>
> http://narwhaljs.org/
Cool! We'll check it out.
Kris Kowal
> Cool! We'll check it out.
I will no doubt be a man in search of a distraction this weekend. Who
do I have to bribe to make a branch of caja and caja-captp for the
purpose of researching Narwhal packaging? Do you have continuous
integration? Is there a system that could be harnessed to post a
package.zip and package.json file somewhere predictable periodically?
Kris Kowal
Jasvir Nagra
I am not sure I understand why you'd need a branch though.
Kevin Reid
Caja-CapTP is only just started and has nothing setup for releases or
automatic testing. (The tests currently only run in a browser, anyway,
because the Updoc framework assumes a HTML document/DOM; I need to fix
this but it's not on the GSoC-activities timeline so won't happen in
the next two weeks.)
If you'd like to work on a branch I can add you to the project and we
can make a branch. I'd certainly appreciate any help with server-JS
matters. Why not, though, check out the code[1] and play with it and
see how much needs to be done? You can always switch to a newly
created branch.
I don't know anything about what the requirements of Narwhal
packaging are yet. However, Caja-CapTP *is* supposed to run on both
browsers and servers, so it does need something like this.
Note that all Caja-CapTP code is cajoled and packed into a single Caja
module. Caja-CapTP will *NOT* run without the Cajita runtime. (It does
not deliberately depend on anything specific to web browsers, however.)
[1] svn checkout http://caja-captp.googlecode.com/svn/trunk/ caja-captp
--
Kevin Reid <http://switchb.org/kpreid/>
Kris Kowal
> We don't have continuous packaging. We periodically push a maven cut
> (http://code.google.com/p/google-caja/source/browse/#svn/maven/caja/caja)
> for Shindig to pull in. It comes with maven-metadata.xml which might be all
> the pieces you need (and all of the pain of maven). Alternatively would it
> be useful for us to do a postcommit webhook?
>
> I am not sure I understand why you'd need a branch though.
Ah, right, your M.O. is to post diffs somewhere for review and then to
commit directly. I'll cross that bridge when I have something to
show. Since this is your process, I'll refrain from directory
structure changes; it's less ideal to go the configuration route over
the conventions, but Narwhal's package.json schema does permit us to
override the default locations for src/, lib/, bin/, packages/ &c, so
that won't be trouble.
Kris Kowal
Kris Kowal
> [1] svn checkout http://caja-captp.googlecode.com/svn/trunk/ caja-captp
Yes, I've already got checkouts of both caja and caja-captp and took a
peek at the latter. It's not a far cry, if at all different, from
Narwhal package layout. I'll see whether I can get it working with
our package installer in a temporary location. One of the advantages
of getting this working is that "tusk install caja-catp" would
automatically install "caja" as well, and put the bin/cajoler on the
PATH, so newbies would get a quick start. You would also be able to
use Narwhal's crypto libs and put JavaScript shell scripts in bin/.
Kris Kowal
Kevin Reid
> On Tue, Aug 11, 2009 at 7:18 PM, Kevin Reid<kpr...@mac.com> wrote:
>> [1] svn checkout http://caja-captp.googlecode.com/svn/trunk/ caja-
>> captp
>
> Yes, I've already got checkouts of both caja and caja-captp and took a
> peek at the latter. It's not a far cry, if at all different, from
> Narwhal package layout.
Note that for deployment use, the *only* relevant file is src/
everything.js. Everything else is either uncajoled source,
intermediates, tests, or build infrastructure.
Also, for anyone interested, I've written up the currently existant
components and files of Caja-CapTP:
http://code.google.com/p/caja-captp/wiki/Architecture
ihab...@gmail.com
> do I have to bribe to make a branch of caja and caja-captp for the
> purpose of researching Narwhal packaging?
Fwiw, how would that work? Are you planning to use only parts of the
Caja runtime? Or to run Narwhal cajoled? If the latter, then it would
be a far more systematic change than simply schlepping in some JS. Is
that indeed what you are contemplating?
[ Sorry if I missed something along the way - on vacation. ]
Ihab
--
Ihab A.B. Awad, Palo Alto, CA