The Life and Times of Michael Shadle

Right now I'm happy. Why's that? Because I have a neat Google Gears-based file uploader that uses hardly any code and no special server requirements or code requirements. It is *almost* everything I've been trying to accomplish with my behind-the-scenes type efforts to scare up some development... and this was accomplished so quickly it was scary.

Big props to Raghava @ work. He did the legwork of putting together the base code that makes Gears work properly and enough for me to play around with. Between the two of us I think we'll be able to conquer the rest of it.

Okay, so what exactly was I hoping for?

• No special server requirements - PHP is all that is needed, data comes via POST
• Not one single huge request - yes, the files are split up in memory at runtime as needed into configurable-sized chunks
• Large file support - yes, as large as any component allows, at least
• Multiple file support - yes, uploads happen in a serial fashion
• Friendly file selection UI - yes, it uses the OS's file browser like a normal file upload
• Friendly web UI - yes - since it's in JavaScript, anything can be done
• Transparent HTTP/HTTPS support - have not tested it on an SSL-enabled box, but I see no reason why it wouldn't work (it's basically like an XHR request)
• Retransmission on failure - no, I believe the Gears developers need to implement additional settings/capabilities into the "httprequest" class - this is the biggest gap
• Pause/resume support - no, I don't think this is supported quite yet in our implementation
• Persistence - being able to resume later on after power outage, browser closing, etc. - no, but possibly an option if integrated into the Gears local database
• Parallel processing (not required, might be neat) - possibly with a Gears worker pool, but not really a big enough deal to bother

Right now what we've got pretty much meets most of the needs. The biggest gap here is making sure it attempts re-transmission. Without that, this is still very cool, but that will be one of the major benefits this exercise could offer.

Perhaps soon I will post some code. I'll want to ask Raghava if he cares first. Maybe some JavaScript/Gears gurus could even clean it up or add more functionality.

This is for 2.6.3 - not sure what other versions it will work on. Originally I got this from http://www.untwistedvortex.com/2008/06/27/adjust-wordpress-autosave-or-disable-it-completely/, however, it was still giving me a JavaScript error.

Note that this worked fine in FF 2.x, and IE6 for English; but for some reason it broke in Chinese and only in IE6. It kept telling me it was failing to update a post, even though it was a new post. I traced it down finally to autosave.js changing the value of the action to "editpost" instead of "post" - I am not exactly sure why the behavior is different in different browsers, but at this point I don't care. The autosave feature is not necessary for the blog site I am supporting for work.

At first I tried a wp-config.php attempt, from http://sheldon.lendrum.co.nz/disabling-wordpress-auto-save-and-revision-saving_227/04/ - but that must not work in 2.6.x - it still appeared to be autosaving. The next Google result was a plugin fashion that dequeued the autosave.js script - which was the culprit, but it wasn't quite complete (at least in my 2.6.3 install) - so here is the complete fix (no JavaScript errors that I can tell)

First, you need to make a file called "autosave.js" and throw it in wp-content/plugins, the content of which is:

function autosave() {
   return true;
}

Next, throw this in an existing plugin or make a standalone file (I have a file with a bunch of random WP "fixes" so I just threw it in there):

function disable_autosave() {
   wp_deregister_script('autosave');
   wp_enqueue_script('wphacks', '/wp-content/plugins/autosave.js', array(), '20081123');
}

add_action('wp_print_scripts', 'disable_autosave');

A big thanks to the guy at Untwisted Vortex for getting me on the right path. I'm sure there might be a couple other ways to do this, but this works just fine, and maps with the primary goal of not editing the core code of the package.

I dislike wikis. At work we were using them. Now we're changing from wikis to an article management system. The idea on paper sounded great, but I'm realizing the pitfalls about the implementation.

There are some traits that wikis have that I like. There's also plenty of bad traits. Also, I'm thinking of MediaWiki when I say this stuff.

Pros:

• Interlinking and updating
• Anyone can edit pages by design
• Templates and categorization can be done by anyone, inline
• Every page has a discussion option

Cons:

• Lots of overhead
• Semi-proprietary syntax (= makes h1, == makes h2, * makes one level lists, ** makes it a two level list, etc.)
• Inconsistent syntax - some HTML works, some bbcode-ish wiki stuff works, some __HEREDOC__ stuff works
• Forces everything to be CamelCase
• No attachments per page, only global
• By default, wikis have no page-level security, since their mantra is "anyone can edit"

So now that I've said that - I have to say that the ideal approach would be to take the existing CMS approach but add in a few wiki features. Specifically the interlinking. We already have a comment feature on every page. Attachment management is per-page too.

Late night half dazed thoughts:

Link syntax couldn't be something like foo:bar - since javascript:foo would conflict. Perhaps something like [foo:bar] would be a good idea? For links to file attachments, [file:fileID] or [article:slug-title]. This would make life simpler for tracking what files are orphans, can display information about the file in-line in the documents (file type, size, etc.)

One thing most places forget to mention, at least clearly, is the need to update the LU tools before you run the upgrade.

This assumes you have the DVD .iso already on the system, and you are mounting it to a directory (in this example, /export/loop)

First update the LU tools off the new disc. This process wasn't really included in a lot of blogs I read:

mount -F hsfs /path/to/sol-nv-b101-x86-dvd.iso /export/loop
cd /export/loop/Solaris_11/Tools/Installers
./liveupgrade20

*Now* you can run all the LU commands:

lucreate -p rpool -n snv_101
luupgrade -u -n snv_101 -s /export/loop
luactivate snv_101
init 6
shutdown -i6 -g0 -y  (if init 6 doesn't reboot - maybe I was impatient)

P.S. Don't put the .iso on your root pool or it will be included in the filesystem forever and you won't be able to get that space back. Thanks Tim 🙂

I comment on a lot of random sites and blogs. I usually write down the URL in a text file and hope that someday I'll remember to return to see if there's a reply.

I believe a service exists - I know that "page change notification" services exist, but I'd rather be able to subscribe to an RSS feed of reply notifications - i.e. I post on a blog, I dump the URL into a textbox, and it monitors the site every so often for changes (probably the specific post's comment feed is the only thing that is worthwhile) - even better, someday maybe even automatically adding the URL when the browser notices I've commented.

Anyone got a site out there that does this yet? I've had this on my mental radar for a while. Of course, that doesn't really do anything if I can never get around to finishing anything.