A big thanks to Jeff for working out the
file format of the new files and to Adrian for working out the new
iTunesDB flags needed to make this work and for updating the gnupod
scripts to work with the shuffle.

After my initial post,
I've been working with the gnupod and foo_pod authors to get them
samples of different iTunesSD and other files to get the formats worked
out. Jeff (foo_pod) has been updating the iTunesDB wiki page
with the file format info for iTunesSD and iTunesStats files that the
shuffle uses. If this kind of thing gets you moist with anticipation,
be sure to check it regularly.

I'm not sure where all this will lead yet but it looks like it will
help Windows and Linux users to be able to use their shuffle with
software other than iTunes. That is a good thing.

I recently changed to Ubuntu Linux on my laptop. I previously used
PdaNet on XP to use my Treo 600 as a GPRS modem and wanted to do the
same thing now. After a bit of searching and some trial and error, I
got it working. Here's what I ended up doing. My provider is T-Mobile
so the Init3 and Phone settings in /etc/wvdial.conf may vary for other
providers.

Edit /etc/wvdial.conf and add the following:

Edit /etc/ppp/options and comment out the following lines (this
prevents pppd from disconnecting after 2 minutes):

After editing the above files and saving them, connect your Treo using
the USB data cable. Depending on which port you plug in to, you may
need to edit number at the end of the Modem setting in wvdial.conf. On
my system, when I plug it in I get two new USB devices created,
/dev/ttyUSB0 and /dev/ttyUSB1 even though only one of them has a device
plugged in. I assume that the kernel activates all ports on the hub.

Download the following app and do a HotSync to install it:
http://butterfeet.org/wireless-modem.prc
This will enable you to put the Treo in and out of tethered mode easily
without having to dial the number manually and without having to reset
it to get out of tethered mode.

On your Treo, start the Modem app you installed above. Choose USB as the port and click on Enabled. Now,
on your computer start wvdial to dial the modem and start pppd using the following:

If everything went well, you should get a connection.
Hit Ctrl+C to disconnect.

References:
http://www.kevinboone.com/treo_notes.html
http://www.1src.com/forums/showthread.php?p=680621
#post680621
http://sourceforge.net/mailarchive/forum.php?forum_id=4987&
max_rows=25&style=nested&viewmonth=200404
http://discuss.treocentral.com/showthread.php?t=49400
&page=1&pp=20

Step One: Create a .src File

The
.src file is what tells the search feature how to conduct the search
and, optionally, how to interpret the results. Here's the .src file I
created: 

<search		version="7.1"	name="Orlando Wiki Search"	description="Search the Orlando Wiki"	action="http://orlando.citywikis.com/tiki-searchresults.php"	method="GET"	target="_blank">

<input name="sourceid" value="Mozilla-search"><input name="words" user=""><input name="where" value="pages">

This
is all that's needed for a very basic search that uses GET (a
querystring URL) to perform the search and displays the results page in
the browser. Let's take a look at this file and what it means.

The version="7.1" attribute of the search tag should be just
that. 
Don't mess with it. The name attribute is what you can use to give your
plugin a name. The description attribute is for the description. The
action attribute is the base URL to your search page. This must be a
page that uses GET (a querystring). This is everything before the ? in
a URL that you would see in your browser's address bar when you do a
search. The method attribute should be GET. Use target="_blank" to have
your results open in a new window (or tab, depending on your config).
Use target="" to open in an existing page/tab.

The next few input
tags are used to build the querystring sent to the server. The sourceid
input should be there and left as it is above--don't ask me why, I just
recall that it is part of the spec. The next two input tags need to
correspond to the GET variables your server is expecting to execute the
search. For example, when I go to the wiki and do a search for wifi,
the URL that is used is: http://orlando.citywikis.com/tiki-searchresults.php?search=go&words=wifi&where=pages

The search=go is the value of the search button on the search page and
isn't used to process the search--you can tell by leaving it our of the
URL. The words=wifi is where the search string I typed is passed in. To
make this into an input tag, take the field name (words) and use that
as the name attribute value. The search terms entered in a Firefox
toolbar search will be passed in as the user value (or at least that's
what I'm assuming since I have no idea about the internals and I'm too
lazy to read the docs ;-). That is where the user="" comes from in the
input tag.

The last input tag is used to specify where to
search.  This is determined by the wiki--I'm just using the
name="where" and value="pages" to match the querystring.

OK, now
you have your .src file. Save it. I used orl-wiki-search.src as the
filename. Note that you will be using the base name (without the
.src extension) of this file later on and it will also show up
in the user's searchplugins folder when it is
installed, so pick something that makes sense.

Step Two: Creating the Icon

When
you load a search plugin, it has an icon that it shows in the toolbar.
From what I gather of the spec, this is optional but having no icon is
just lame, so let's create one. Use your favorite image editing program
to create a 16×16 PNG file. You can use GIF also, but I couldn't get it
to work and don't really care why since PNG worked fine ;-). Save that
file with a .png extension using the same base name as your .src file.
This is important if you want it to work. Since my .src file is
orl-wiki-search.src, my icon file is orl-wiki-search.png.

Step Three: Adding JavaScript and Creating the Install Link

To install a search plugin, you have to use a bit of JavaScript code which you'll call using a link. Here's the code:

<script type="text/javascript">function addEngine(name,ext,cat){	if ((typeof window.sidebar == "object") 		&& (typeof  window.sidebar.addSearchEngine == "function"))	{		window.sidebar.addSearchEngine("http://chris.geekcollective.com/" + name + ".src",			"http://chris.geekcollective.com/" + name + "." + ext,			name, cat );	}	else	{		//you could put an error handler here		;	}}</script>

Put
this in the HEAD of your page or an external .js file that is linked in
to your page. You can put it in the BODY in a pinch (as I did since I
put this on my blog and doing per-page HEAD modifications wasn't
something I wanted to think about. I was lazy and didn't feel like
changing the script I lifted to figure out the base URL of the site it
is on so you'll need to change http://chris.geekcollective.com/ to your own site if you use this. Other than that, this doesn't need to be modified.

To create the link that will be used to install, use the following HTML code:

<a href="javascript:addEngine('orl-wiki-search', 'png', 'Orlando Wiki Search')">install it</a>

Change
orl-wiki-search to the base name of your .src and .png files. Leave png
as it is unless you are using a gif file, then change it to gif. I'm
sure the third parameter for the category should be something different
but since I couldn't find any good docs on it, I made up my own. It
seems to work, but if anyone has any info. on this, I'd like to know.

That's it. See it work here.

TikiWiki is very nice. I used it to set up the Orlando Wiki and was very happy with everything you could do with it until Dan
looked a the wiki and said something to the effect of "good, now let's
rewrite those URLs to get good search engine rankings". After a heated
IM debate on whether it mattered to Google if links to the wiki pages
were querystrings (e.g. http://orlando.citywikis.com/tiki-index.php?page=HomePage) or if they were SEF (search engine friendly) URLs (e.g. http://orlando.citywikis.com/HomePage)
I was swayed by Dan's persuasive argument (which boiled down to: you
are wrong and I know it) and decided to change the URLs to be SEF.

I
figured we could use mod_rewrite in a .htaccess file to rewrite the
incoming requests to something that TikiWiki can understand. This
turned out to be easy when I came across a post describing how to do this.
So, now we have the incoming links being rewritten, but what about the
links the TikiWiki spits out? Since it uses Smarty, we can hook into
the page processor and rewrite the output before it is sent to the
browser. Someone had already described how to do this, so I had a place to start.

Basically,
you have to write a function that the Smarty output
filter can use. I used the code in the article above as a base. To
do what I wanted was much simpler--at least it was after battling to
get the correct regexp. Here's the code I used as the output filter:

<?
function smarty_outputfilter_urlt($string) {
     $result = preg_replace('/<a(.*?)href="\"tiki\-index\.php\?page="(.*?)\"(.*?)"">/',
        '<a$1href="$2"$3>',$string);
     // If the page was passed in an action, the link that was
     // 'tiki-index.php?page=foo&action=lock' will now look like 'foo&action=lock'
     // The first & needs to be converted to a ?
     $result = preg_replace('/(href=\"[a-zA-Z0-9]+?)(&amp;|&)/', '$1?', $result);
     return $result;
}
?>

I saved that as outputfilter.urlt.php and uploaded it to the
lib/smarty/plugins directory. The next step was to add the following
line at the end of the code in setup_smarty.php in the root of the site:

$smarty->load_filter('output','urlt');

This filter rewrites the URLs to be more SEF. Check out the home page of the Orlando wiki for an example.