Dynamic DNS will direct internet traffic to your home router. Port forwarding will forward incoming traffic on port 80 on the router to port 80 on your main server. The mod_proxy Apache settings will redirect HTTP traffic intended for server1 and server2 over to those servers through the main server.

You can manually update your IP address at dyndns.com, but once your home IP address changes, that information will be out of date. Linksys routers (and possibly other brands) come with dynamic DNS clients that will update your IP address for you when it changes. Alternatively, you can install a dynamic DNS client on one of your home machines that will connect to the internet on a regular interval to keep your home IP up to date.

Usually, your router will block all incoming traffic from the internet to your home network. You can set up port forwarding to redirect traffic on specific ports to ports on your internal servers. Check out your router's documentation for how to configure port forwarding.

Dynamic DNS and port forwarding will let you hook up one server. To add server1 and server2, we need a way to direct requests for those servers through the main server. This is where mod_proxy for Apache comes in (if you're not using Apache, you're on your own at this point). We will set up virtual host entries for the other internal servers and use the ProxyPass directive to forward traffic intended for the subdomains. You will modify your httpd.conf file as follows:

1. Uncomment following lines:

LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so

2. Add following lines:

ProxyRequests On
NameVirtualHost *

<VirtualHost *>
ServerName server1.yourhouse.homeip.net
ProxyPass / http://192.168.1.110/
</VirtualHost>

<VirtualHost *>
ServerName server2.yourhouse.homeip.net
ProxyPass / http://192.168.1.111/
</VirtualHost>

where 192.168.1.110 and 192.168.1.111 are internal ip addresses or machine names for your internal servers.

Then, restart your Apache server and you should be able to connect to your machines.

SharpScraps Highlight of the Day

Voice Recognition and Text-to-Speech

SharpScraps.Speech contains some wrappers for the Windows APIs for voice recognition and text to speech conversion (see SharpScrapsExamples/TextToSpeech and SharpScrapsExamples/VoiceRecognition in the code drop to see how to use them). Voice recognition opens up some interesting possibilities. A few years ago (long before the Ford Sync voice control commercials started showing up), I put together a voice control program for iTunes. It used the iTunes COM control for retrieving the list of music in the library and used that as the basis for the phrase list fed into the SharpScraps.Speech.Recognition.PhraseRecognizer class (names such as "U2" were replaced with "you two" to help the system out). Then, if you said "Metallica", it would kick off a playlist containing all of your "Metallica" songs. If you said "still haven't found what i'm looking for", it would tell iTunes to play just that one song. At one point, I had the hopes of hooking up a Bluetooth earpiece, so I could walk around the house controlling my computer and asking it for information. Unfortunately, the Bluetooth drivers never seemed to support the headset profile, and even if they do now, I suspect the audio quality might not be high enough to make things work smoothly.

Text-to-Speech is the reverse of voice recognition. It takes textual input and converts it into audio. The SharpScraps example shows how to play the audio aloud or save it as a WAV file. The test dialog will let you select from any voice that is installed on the system. I believe Microsoft Anna is the only voice that comes with Windows, but better voices can be licensed from third-parties. On Windows XP, you might have to manually install the speech SDK (google 'microsoft sapi sdk'), or Microsoft Office might have installed it for you.

Anyhow, much fun is to be had with voice recognition and text-to-speech. Knock yourself out.

http://teethgrinder.co.uk/open-flash-chart-2/

set completion-ignore-case on
# Ignore case when doing completion

set mark-directories on
# Completed dir names have a slash appended

set visible-stats on
# List ls -F for completion

"\C-i": menu-complete
# Cycle through ambiguous completions instead of list

#set show-all-if-ambiguous on
# List possible completions instead of ringing bell

Blogs, wikis, and a software release repository would be types of "modules". By software repository, I mean something that would track the latest release of QuoteBlizzard or FlowBasis and know the latest version numbers and download links.

"Modules" tend to contain "resources" that should be searchable and/or rateable. Blogs have posts and comments. Wikis have user created pages. Software release repositories have projects. A developer should be able to create a custom module that tells FlowBasis, "Here are my resources," and FlowBasis should be able to incorporate them into the search engine and provide ratings tracking.

"Modules" also tend to have information that would be nice to easily incorporate into other page views in the form of "widgets". A blog could publish "widgets" for its tag cloud or recent posts. A wiki could publish "widgets" for top-rated pages or most recently updated pages. A software release repository could expose a "widget" that displays the most recent software releases with a download link.

Any page view can incorporate widget panels, and widget panels can be configured through an AJAX-y interface. For instance, you can add a widget panel to your main site page and through the browser (if you have permissions), you can add widgets by browsing through a list of available widget templates provided by modules, or configure existing widgets (such as change the URL on a feed listing widget or change the maximum number of displayed feed entries).

A sample JSON object declaration might look like (in Javascript, the quotes aren't required around "username" or "favoriteNumbers"):

{ "username" : "bob", "favoriteNumbers" : [42, 37, 100] }

In PHP, this could be declared as:

$bob = new stdClass;
$bob->username = "bob";
$bob->favoriteNumbers = array(42, 37, 100);

and it could be converted to JSON with:

$json = json_encode($bob);

But, usually, the FlowBasis infrastructure will convert the PHP object into JSON where needed.

The three basic types of request handlers are:

• Basic file handler
• Page request handler
• Site path request handler (extensible handler model used by modules)

The basic file handler is for requests that map to a static file (html, png, gif, javascript, css, etc) and just returns the file contents.

The page request handler kicks off the page processing model (see a future post for details on that).

The site path request handler system is used by modules (blog, wiki, etc) to register for requests to particular URIs. Custom site path request handlers can also be created by developers interested in doing something completely different with a request.

The process of selecting the appropriate request handler goes through a series of steps, which essentially boils down to picking the request handler that is interested in the longest prefix of the request uri.

Consider the following scenario, where a user makes a request to get http://test.calevinci.com/flowbasis/someblog/img/hello.png.

Let's assume the following:

• FlowBasis is installed in /var/www/flowbasis (and test.calevinci.com maps to /var/www). This means that /someblog/img/hello.png is the site path. /flowbasis is the request URI root.
• The file /var/www/flowbasis/pages/someblog/img/hello.png exists.
• A blog module is set up and registered with the site path someblog.

The routing manager will look in several places for possible matches. It will look in the pages and core-pages directories for files and pages (core-pages is for the FlowBasis infrastructure, and sites built on FlowBasis should use pages). The routing manager will also look at registered site path handlers.

The basic file request handler will want to process the request with a matching site path of /someblog/img/hello.png. The module site path handler will want to process the request with a matching site path of /someblog (with an extended site path of /img/hello.png). The basic file request handler has a longer matching site path, so it wil get to process the request.

Now's let assume the user makes a request to get http://test.calevinci.com/flowbasis/someblog/tags/trees.

No file exists at either /var/www/flowbasis/core-pages/someblog/tags/trees or /var/www/flowbasis/pages/someblog/tags/trees, so the module request handler will get the request with a matching site path of /someblog and can map the extended site path of /tags/trees to a page with recent posts tagged with trees.

The object store provides a few basic methods: getObject, saveObject, and updateObject. Beyond that, there are a few additional methods for retrieving lists of objects and locking objects for synchronization. The default implementation of FlowBasis_Data_IObjectStore saves and loads everything to and from the file system, but the door is open for future implementations which use a database or the "cloud" for storage (though I imagine more intelligent use of caching would become necessary as the object store moves farther away from the local server).

All that said, if you really want to use SQL with FlowBasis, you're welcome to use it. FlowBasis incorporates the open-source adodb library and provides a management panel for configuring connections and trying out SQL queries.

• Pages can contain controls which can contain other controls.
• Pages and controls can communicate from browser to server via remote procedure calls (JSON-RPC).
• Modules (blog, wiki, etc) contain resources (posts, comments, pages, etc).
• Resources are indexed for searching.
• Modules (blog, wiki, etc) or other sources can publish widgets (recent posts, tag cloud, html snippets) that can be embedded in other pages.
• Resources can be rated.
• Anything can publish events to the event manager. Anything can subscribe to events with an event handler.
• Task handlers can be registered to perform tasks that must be done periodically in the background (like cleaning cache).
• Installers manage adding and removing features/modules/whatever from the system.
• Permissions define what users can do within modules (such as post an entry to a blog).
• Users can have roles which grant them permissions (such as only admin and author could post an entry to a blog).
• Roles can apply to specific contexts (user can be admin for whole site or just a particular blog).
• Themes collaborate with pages and controls to determine the visual style of the site.

• Add a file (regular old PHP, HTML, png, gif, whatever) within the "pages" folder.
• Add a FlowBasis_UI_Page declaration in a PHP file with FlowBasis::setPageClass('NameOfPageClass') within the "pages" folder.
• Use one of the built-in modules (currently blog and wiki).
• Create your own module class.
• Register a site path request handler with the routing manager and use your imagination from there.

Over the next few days, I'll try to make a series of posts to give the general idea of what you can do with FlowBasis, so stay tuned...