» tagged pages
» logout

(Feed found, click Add Page to syndicate.) Error finding feed, please try again » Find feed title

A Blog Page allows you to add entries, for news or other time sensitive postings

(Login required to save to your tagged pages.)
(or Cancel)

Make further edits, (or Cancel)

(Login required to save to your tagged pages.)
(or Cancel)

(Editing anonymously: to be credited for your changes, login or register a new account)

Change Page Permissions? Changing these permissions will adjust who can modify this page.

Anonymous (change)
(change)
(or Cancel)
Upload an image from your computer:
or Copy an image from a URL:
or Erase the current icon:
Icon Preview:

or Cancel

Erase 9? The contents of 9 page and all pages directly attached to 9 will be erased.

or Cancel

(Editing anonymously: to be credited for your changes, login or register a new account)

other page actions:
9

9

Tags Applied to 9

No one has tagged this page.

9 Wiki Pages

What is 9? Edit this page and describe it here.

sorted by: recent | see : popular
Content Tagged 9

Service Oriented File Systems

Its fun to abstract and think about web2.0 concepts in terms of Plan 9 concepts. Abstract away the gorp that makes up their implementations and think about some of the fundamental concepts. When interfaces are files, mashups are binds.

The larger picture here is about keeping this simple, language independent, and client independent. I'd like an infrastructure that I could build simple web services out of that can be viewed with a browser, or with a rich-client (like acme plug-ins). I'd like the front-end of these services to be defined in the same way the Octopus approach defines normal GUI's (except from a web-browser, the widgets are implemented by Java script). I'd like the back-end of these to be akin to big table and the chubby lock service, with a back-back-end that is simply Venti versus a database or XML.

I'll admit I'm probably naive about all of this, not having really worked on client-facing applications for some time, but I think it would be a fun thought exercise to go through and perhaps a nice refresher to actually try and implement. While part of the goal is to keep things language independent, I'll probably do things under Inferno to keep them portable for me and open up the potential for interaction with the Octopus crowd.

Of course, this all falls under the copious spare time which I have a definite deficit of -- however, I think dedicating one day a week is doable and I should be able to combine this with my constant desire to get back and look at collaborative facilities (aka warren) under Plan 9 and Inferno.

v9fs: Grave Robber's from Outerspace

Blue Gene Project Pages

I've setup an more official website to put publications and presentations relating to the DOE sponsored Plan 9 on Blue Gene work. You can get to it here and I'll be updating it over the next few days.

v9fs: Grave Robber's from Outerspace

Torus and tree networks working on Plan 9 BG/L port

We finally worked out the remaining infrastructure issues and are now able to cpu(1) to both I/O nodes (over the Ethernet) and cpu nodes (over the tree network). The cpu nodes are also able to talk to each other over the torus network.

We will be attempting a live demo during the USENIX poster session, so drop by and play with Plan 9 running on a Blue Gene.

v9fs: Grave Robber's from Outerspace

Service Oriented Synthetic File Systems

I was doing some thinking about how larger synthetic file systems are structured and implemented under Plan 9 (or using 9P in general).

My toy-use-case for thinking about it was developing a synthetic-file-server based service similar to SourceForge -- where you have many different projects, each with different component services (bug-tracking, version-control, blogs, wiki, forums, etc.)


You could do it by running lots of different servers (per project) and binding them into a name space and then exporting, but that seems kinda awful (particularly if you have dozens of projects you are using the same tool to track). Much better to have a single server running which is able to accommodate multiple projects, each with multiple file services underneath.

Obsession with qid-spaces ends up being distracting, with the way fids work, we shouldn't need to segment the space so rigidly, it seems to me that qids only really need to be unique per directory, outside of that you can track which "module" of the hierarchy you are in by saving some state in the server-side fid tracking structure as you traverse the hierarchy.

dot-dot makes things a little more complicated, but the solution used inside the kernel can be used within file servers as well (namely, keep the whole path in the service-side fid tracking structure).

What's really nice is you can develop plug in file server modules which allow you to compose much more complex single-server-services out of many different file system components -- without worrying about how the qid space is split up and managed.


v9fs: Grave Robber's from Outerspace

GSoC 2008 Ideas

My Plan 9/Inferno summer of code ideas (otherwise known as projects I wish I had more time for) - projects should take no longer than 5 weeks to complete (including ramp up, debug, and packaging) -- conservatively projects should be completable in 3 weeks by experienced P9/Inferno developers and 2 weeks by folks unfamiliar with p9/inferno development environments.
  • mount.9P helper program for v9fs including packaging for debian and fedora -
    • hueristic for determining transport type
    • DNS support for resolving hostname <->ip address
    • ssh-based tunneling support (will require server work as well)
    • man pages
    • debian packaging
    • rpm packaging
    • (stretch) authentication support (w/p9p)
    • (stretch) authentication support (w/o p9p)
    • (stretch) integration with idmap solution
  • since this is relatively straightforward it will really need to be "super" version including support for ssh tunneling, authentication, etc.
  • idmap solution for v9fs - maps local uids/gids/error-codes to strings
    • userspace daemon to provide mapping
    • hooks in v9fs to use mapping
    • (stretch) synthetic file server approach to update mappings
  • OLPC Inferno Environment
    • fontfs - on-demand ttf solution
    • metafs - abstract metadata from underlying file system
    • (stretch) Integrate OLPC translation solution for Inferno
    • (stretch) OLPC oriented GUI toolkit, window manager, and toolbar
    • (stretch) Inferno approach to collaboration using file systems
  • Source Control Management based on Venti backend
    • single branch version tracking with associated log file
      • add new files/directories
      • commit changes
      • checkout specific version #
    • (stretch) support multiple branches
    • (stretch) support repository sync (push/pull)
    • (stretch) support three-way merge
  • wrapper for p9p vbackup to make it more user friendly
    • wrapper which tracks venti scores based on volume being backed up
    • GUI admin tool
      • which sets up venti in partition(s) or with files
      • which assists in configuring backup intervals and volumes
    • (stretch) time-traveler like GUI for navigating/searching backups
    • (stretch) support for pruning and/or merging snapshots
  • GSoCFS for managing future community involvement with GSoC
    • synethtic file system and web interface
    • posting project ideas
    • voting for projects
    • registering student interest in projects
    • project milestone tracking
    • project blogs and wikis
    • post-summer project success metrics (subjective and objective)
    • (stretch) syndication points for community monitoring
    • (stretch) potential integration with SCM
    • (stretch) potential integration with some form of chat
    • (stretch) potential integration with name space sharing
(more to come...)

v9fs: Grave Robber's from Outerspace

SWF9 runtime target, coming together

We’ve got the basic core of OpenLaszlo compiling and running in SWF9. Thanks go to the good folks at g.ho.st (Global Hosted Operating System) for their support in this development. Here is a simple Laszlo app compiled to swf9 format and running in Flash 9. If you don’t have a Flash 9 player installed, you won’t be able to see it.

Simple SWF9 Demospinner

This is the source code for the app above:

 <canvas width=\"800\" height=\"600\"> 
	
  <view id=\"bar\" x=\"200\" y=\"200\" >
    </view><view id=\"foo\" bgcolor=\"0xcccccc\" x=\"-100\" y=\"-100\"  height=\"200\" width=\"200\"
          onclick=\"this.parent.animate('rotation', 90, 1000, true)\" >
	
    <text fontsize=\"18\" fontstyle=\"italic\">This is some text in a text view</text>
	
    <view bgcolor=\"blue\" width=\"40\" height=\"40\"
          x=\"59\" y=\"59\"
          onclick=\"this.animate('x', 10, 1000);
                   this.animate('y', 10, 1000)\"/>
	
    <view bgcolor=\"red\" width=\"40\" height=\"40\"
          x=\"101\" y=\"59\"
          onclick=\"this.animate('x', 150, 1000);
                   this.animate('y', 10, 1000)\"/>
	
    <view bgcolor=\"green\" width=\"40\" height=\"40\"
          x=\"59\" y=\"101\"
          onclick=\"this.animate('x', 10, 1000);
                   this.animate('y', 150, 1000)\"/>
	
    <view bgcolor=\"yellow\" width=\"40\" height=\"40\"
          x=\"101\" y=\"101\"
          onclick=\"this.animate('x', 150, 1000);
                   this.animate('y', 150, 1000)\"/>
  </view>
	
</canvas>
	

A number of things have to be working to support this application:

  • Kernel Sprite implementation
  • LzEvent and LzDelegates
  • LzNode is able to instantiate nodes with children, init methods, and setters
  • LzView can create and manipulate kernel Sprites
  • Idle events can be regsitered, so that animators can operate
  • Kernel mouse events are forwarded to the LFC and dispatched to registered listeners
  • Integration between the Laszlo compiler and the Flex mxmlc compiler

All of these are implemented, although the kernel sprite support needs to be fleshed out and optimized.

Things major that still need to be brought up in swf9 are

  • constraints: we’re not allowed to store the dependency functions on function in swf9, so we have to make the compiler put them someplace else
  • XML data loading and parsing
  • node replicators
  • media playback
  • drawview
  • keyboard handling
  • text and inputtext views
  • browser/player communication
  • debugger (although the Flash fdb debugger can be used for now)
  • Selection manager, font manager
  • embedded assets,fonts

We’re got the development going on in a branch named “devildog”, and in about a week or so should have things in place to allow people to start helping out if they want to get certain modules or features completed sooner, or fix bugs or optimize for the Flash 9 platform. There are a lot of new and improved APIs provided by the Flash 9 runtime; better media loading, data loading, and network APIs, as well as much more rational imaging and event model. We can probably take a lot of advantage of these by updating and optimzing the swf9 kernel and the runtime to use this where possible.

An quick overview of the approach to compiling to swf9 is outlined below.

The Flash 9 runtime contains a new virtual machine which has efficient support for JS2 style classes. If type declarations for variables and methods are provided, and use of some dynamic Javascript features is avoided, the application can run faster.

The Laszlo compiler emits AS3-compliant javascript class files, which are compiled by the Flex AS3 compiler, to produce an executable swf9 binary application file.

We currently compile the LFC library as a separate .swc AS3 library file, which is linked to the user application when the application is compiled.

Our plan is to have the LZX tag compiler phase emit real ‘native’ JS class declarations for user-defined classes (and all views, in fact). The LFC is already defined as JS2 style classes, using our own Class.lzs class system, designed by Tucker. We are converting these to be actual JS2 classes, which means no longer using our class initializer protocol. Stuff that is in now in class and instance initialize methods must be coded in some other manner.

Classes which are declared ‘dynamic’ in Flash 9 are slower to execute, since they must look up methods are variables by name at runtime, so we have been avoiding declaring LFC classes this way unless absolutely necessary, and would like to go back again and make another pass when things are all working to see which classes can be optimized to use only static lookups. We probably need to leave LzNode dynamic, given that we allow setAttribute at runtime on arbitrary properties, but there is a lot of room for optimization in the support classes in the system.

OpenLaszlo: OpenLaszlo Project Blog

Page 1 | Next >>
Username:
Password:
(or Cancel)