The posts below this one in the queue represent the notes I've made over the past few months on features I'm thinking about that could potentially be added to the Ode blogging system either as addins or core functions.

Some are simply calls for documentation that I would be very comfortable creating myself, in case you are wondering.

Others represent Perl development work.

These entries are here more to encourage discussion among current and potential users of Ode than anything else. So please do.

Level of difficulty: Medium

Description

Modify the HTML and CSS in the main Ode theme so it is fully "responsive" and scales on mobile devices.

Notes and questions

• Hans Fast's Surfacemarkup.com Ode site has a responsive theme. The changes could be incorporated into the main Ode HTML theme, and perhaps Hans would allow his theme to be incorporated into the Ode files and/or offered as a downloadable theme.

• This is a great Ode development project, as would be the creation or modification of any theme. It's one of many learning opportunities that involve working with HTML and CSS and don't require knowledge of Ode's core programming language, Perl.

Level of difficulty: Low to medium

Description

Pagekite is a Python-based service that allows you to maintain a home server and offer material on that server over the Internet via tunneling without exposing your server directly to the network.

This is a potential solution for those who want to run Ode on their home server but are uncomfortable exposing that server directly to the Internet.

These instructions would build on the Ode installation documentation by showing how to set up a home server and integrate it with Pagekite. The instructions would detail the requirements for hardware, software and Internet connection, as well as how to start and configure a Pagekite account to tie it all together.

Level of difficulty: High

Description

If I'm not mistaken, there is more code in the EditEdit addin than in the whole rest of the Ode core. EditEdit -- which brings a web interface that allows creation of new and modification of existing Ode posts -- is complicated.

EditEdit is great in a Web browser on a traditional PC, but it performs poorly on an iPad (a lack of scroll bars on the post window makes it impossible to write and edit all but short posts) and on mobile devices. Turning EditEdit into a mobile-enabled app or site would solve these problems.

Notes and questions

There are two ways to go: HTML5 or native iOS and Android apps. Professional app developers often say the increased performance of native apps is worth overcoming the difficulty of writing to both of the major device families.

But HTML5 apps are independent of the various devices' ecosystems and potentially scale across all desktops, laptops, tablets and smartphones.

If the tasks performed by EditEdit are relatively light, HTML5 could be more than adequate.

• Security is a concern when using a Web-based app like EditEdit. It can be hard to establish a secure connection with the Ode filesystem on shared-hosting accounts that don't have their own SSL certificates. Strong passwords are a must. There is an element of "security by obscurity" at work here.

Level of difficulty: High

Description

Commenting for Ode is currently handled with a Disqus addin that integrates the popular hosted commenting platform with the self-hosted Ode system.

A native Ode commenting system -- also integrated via addin -- would either create its own text files, or add to existing post files, via a comment form that would appear at the bottom of individual entries.

Perhaps a native Ode commenting system could interoprate with Disqus, so a blog's Disqus comments could be converted to native Ode comments, and vice versa, like the way Disqus works with WordPress?

Notes and questions

• Is there anything in Blosxom or Pyblosxom that could repurposed for an Ode commenting system?

• Is there anything in the Chronicle Blog Compiler commenting code that could be repurposed for an Ode commenting system?

Level of difficulty: Medium to hard

Description

The latest (as of early 2013) thing for blogging systems is a site that draws its post files from Dropbox via the Dropbox API. The idea is to write posts in a designated folder/directory in your Dropbox and have those files automatically pushed to the web via an external blogging application.

This could seem counterintuitive at first, especially because the two other systems that I know are using Dropbox in this manner -- Calepin and Fargo -- are both hosted services, while Ode is self-hosted.

The potential benefits of creating and delivering posts via Dropbox for Ode are many:

• Write posts in a subfolder of your Dropbox folder and have them appear in your blog on demand (or after a re-indexing by those using the Indexette addin). Creating content is as easy as writing a text file to your local drive. No FTP application is needed.

• Posts are automatically synched across all of your systems using Dropbox and are automatically backed up (though additional backup measures are strongly recommended)

• A single Dropbox subfolder could feed multiple Ode sites. Or multiple subfolders in a single Dropbox account could feed multiple sites. Users could collaborate via shared Dropbox folders. This could simplify document management in potentially complex situations.

• Content is independent of the server hosting the Ode script. Whether this is an actual "benefit" or simply a consequence is open to debate.

Notes and questions

• Would this be implemented as an addin, or a series of modifications to the main Ode script?

• Development of this addin/added feature would depend on what is required by the Dropbox API.

I used to have one of these Sinclair ZX-81 computers. It plugged into the TV, allowed you to enter programs in BASIC, and save and load those programs and others via a cassette tape recorder.

It was a computer, and it cost .

I had two of the 16K memory modules that plugged into the back. They shorted out more often than not and crashed the computer.

I even subscribed to a Timex-Sinclair-related magazine that offered programs you could type in. Most didn't work. Maybe it was due to typing errors on my part, but you never know.

I eventually put the whole lot into a box and sold it off at a garage sale.

Maybe not so curiously, I think we should still be able to buy computers for . You sort of, kind of can do that.

I'm watching for new AMD video drivers for Linux, both the open-source driver that ships with most Linux distributions and the closed-source Catalyst driver from AMD that you can install with between a little and a lot of difficulty (and potential heartache).

Since I'm running Fedora, mainly because its developers are very pro-active in pushing new code, here's where I'm looking in the Koji Build System for the latest xorg-x11-drv-ati:

http://koji.fedoraproject.org/koji/packageinfo?packageID=95

Right now there's a version 7.1.0-5 in Fedora 19, and a 7.2.0-0 built for the in-the-future Fedora 21.

It might be better to follow the driver upstream:

http://cgit.freedesktop.org/xorg/driver/xf86-video-ati
and
http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/log/

As far as the closed Catalyst driver, keep an eye on this AMD page:

http://support.amd.com/us/gpudownload/linux/Pages/radeon_linux.aspx

The stable driver remains version 13.4, released on May 29, 2013. The current 13.8 beta, released on Aug. 19, 2013, works well enough on my system but doesn't support successful suspend/resume, though the previous beta version 13.6 did. I'm hoping for better suspend/resume results in the next release.

What I'm really hoping for is a open-source driver that supports both 3D acceleration and suspend/resume. Maybe it'll happen at some point in the future. That it hasn't happened yet is what is making me rethink AMD in favor of Intel graphics.

(My AMD APU's GPU is part of the Trinity series and is categorized as such in Wikipedia.)

Just go there: BILL WATTERSON: A cartoonist’s advice

I'm having a problem with permissions on images when I work over sftp with Xfce's Thunar file manager, namely the lack of read permissions, which I've had to use an alternative ftp client (in my case FileZilla) to fix.

I uploaded this photo of myself with GNOME's Nautilus file manager to see if the permissions out of the box were correct in that application.

They are.

I'll have to figure out what's going on with Xfce's Thunar file manager, ftp/sftp and permissions.

Later: I didn't have permission issues in Thunar when uploading a PNG image a couple days ago. Maybe this was a temporary thing? I'll have to upload some more images to test.

Regardless, Thunar has come a long way in recent years.

Even later: I just uploaded a JPG via Thunar, and permissions were fine. Crisis over.