KFM2: the beginning

KFM 1.x has reached the end of its development. It has fulfilled its original purpose; to improve on the default file-manager for FCKeditor, and well-exceeded it.

From my records, I can see that KFM has been installed on over 9000 separate domains. That is quite a lot of sites, and says quite loudly how important it is that KFM2 is at least as good as KFM1 (we all know about the KDE4.0 fiasco…).

KFM2 will blow KFM1 well out of the water. It will do everything that KFM1 does, but much quicker, and with a much less monolithic architecture, allowing it to be hugely flexible. I am planning on creating a download section similar to jQuery UI’s, where you can choose the components that you want in the system, and it will be built up and configured for you, ready for download.

See, KFM 2 will be modular. If you just want a simple upload/download facility, then you will only need the core, and plugins to handle uploads and downloads. If you want the whole shebang, you will find plugins for various ways of selecting files and directories, full-on graphical UIs such as the existing KFM1 forces on the user, plugins for hooking into external file systems using FTP or whatever other method people can imagine, plugins for multi-media, file editing, databases, user authentication, search, RSS, and so on.

Basically everything that KFM1 already does, but with the option to easily remove/add bits that you want. Make it as fast or as “bling” as you want.

KFM2 will have a number of new things which are not available in any other online file-systems, that I know of.

new file-system things

The file system will be modular. You will be able to attach symbolic links to any part of the file system, linking to other external systems.

As an example, let’s look at a URL: http://example.com/kfm/get/images/site1/logo.jpg.

One of the new ideas is that this will not necessarily be located on the server named example.com.

If you are running a very busy website, you might prefer to delegate image management to a different machine deeper in your network, so you add a symbolic link /images/ linking to the image-management machine. This causes the server to issue a redirect to the browser, redirecting it to http://images.example.com/kfm/get/site1/logo.jpg.

Now, imagine that the image management server doesn’t host the logo.jpg file on itself. Maybe it’s one of a number of images.example.com servers in a load-balancing cluster, and the file is actually located on a file-server accessible only by FTP. So, we add a symbolic link in the server’s KFM, telling it how to connect to the FTP server. The image server does this, gets the required file, and sends it to the browser.

This sounds a bit complex, but at least it’s possible with the new system. The old system simply would not be able to handle that at all.

API

At the moment, if you want to select a file or directory, you fire up KFM1, wait 15 seconds for it to finish booting itself up, and select the file or directory. That’s way too long. Really, you should only need to load up a tiny widget that’s designed specifically for picking a file.

The new system will have a simple core with an API that can be connected to by little JavaScript widgets. As an example, let’s say you just want to get the file-listing for the foo directory.

At the moment, you need to go through the whole business of booting up KFM’s GUI, navigating to the right directory, then waiting for the server to connect to the database, generate thumbnails and other unnecessary stuff.

You should just have to do something simple like load up http://example.com/kfm/rpc.php?a=get_file_listing&v=/foo through jQuery’s $.get() function. The RPC script does exactly what was asked, and nothing more.

This should allow us to write some incredibly fast and tiny scripts for all the file manipulation things you could possibly want.

Think of it as the “gnu” way of doing KFM – many small tools, each of which is designed to do one task well.

Of course, you will still be able to use the original GUI with this, after it’s been re-engineered to hook into the new RPC system.

Or, you can write your own – the RPC’s API will be well-documented, and will use simple HTTP parameters, so you can write your widgets in whatever language you want – JavaScript is what I will be writing in, but there’s no reason why you’re confined to that – write a GUI in Python, C, Flash – whatever you’re comfortable with.

plugins

I think the new plugin architecture will make this profoundly extensible. I’m writing the core to be as flexible and stable as possible. You will be able to write a plugin to just about anything:

  • authenticate a user before serving a file.
  • change a user’s root directory based on the server-name or the user’s authentication.
  • the entire system is held on a different machine accessible only by FTP? fine – let’s change how files are accessed.
  • record all files and directories in a database, allowing searches to be done.
  • manipulate files online – edit text files, rotate or crop or resize images, move or rename or delete, etc. standard KFM1 stuff, these.
  • create a log plugin, so all access is recorded.
  • create a quota plugin, for denying uploads or downloads when the quota is exceeded.

It was possible for us (Benjamin and myself) to write all of these into KFM1, but as we are only two people, and very busy people at that, it’s never been the absolute top priority to get all these things done.

But, when KFM2 is released, you won’t have to wait for us anymore. You will be able to write plugins, or download plugins created by other people, which do all of the above and I’m sure there will be plugins that I simply have not imagined yet, that inventive people will come up with (Conor, I’m sure you’ll be one of those!)

languages

Languages have always been one of the cool things about KFM. Version 1.3 was released in about 13 languages in total. Unfortunately, the code got too complex in 1.4 to easily add more, but KFM2 is starting from scratch with the learning-curve of KFM1 well behind me. I’ve already made most of the big mistakes I’m likely to make, so from now on, things should be much easier.

How languages will work is that a website will be created which allows people to help out open-source projects, not just KFM by providing translations of words and sentences.

The programmer will create a screen-shot showing the text in use, and will provide the untranslated text in a format such as .po. Translators will translate the text on-line, and the translation will be available to download by the programmer as soon as it’s done.

To ensure good translation, each line will be presented to a number of different translators. The translations which agree the most with each other, will be considered the “right” one.

Using this, it will be possible for KFM to organically add languages with no interaction from myself or any other programmers. When first loaded, a plugin would try to translate messages into the user’s language. Finding that it doesn’t have the language in its database, it will try downloading it from the language translation website. If it’s not available, a request will be added that it be created. When translators that speak that language come to the website, they will be automatically given the KFM text to translate to that language. The next time the plugin checks, the translation might be done, and it will be added to the KFM instance’s local language database.

Of course, people don’t just do this stuff for the hell of it. It’s more fun if there’s a competition or reward. It would be nice if I could get a few paying customers to add their own translation requests to the website – that way I could offer a reward to the best translators (those that do the most work, or are the most consistent).

The competition aspect comes in, where you give people points for every translation they do that is matched by someone else’s translation of the same text.

Google does a similar thing, for example, where it shows images to people and asks them to come up with keywords describing the image – the commonest keywords are considered to be correct. Same trick, different target.

Anyway! Without further ado, I have a core to design, and tests to create. I was going to talk about testing with PHPUnit, automatic upgrades, and the like, but to hell with ye all – I’ve work to do 😉

unclickable inputs in sortables (and workaround)

Got a call today – a form I created which had some sortable elements was not allowing its contained inputs to be clicked.

After a little investigation, I found this is already reported as a bug.

The workaround is to apply the sortable as usual, using the $().sortable() call, and then after that, override the sortable’s mousedown and click events to force inputs to be selected when they’re clicked.

  $('#form_fields').sortable();
  $('#form_fields input').bind('click.sortable mousedown.sortable',function(ev){
    ev.target.focus();
  });

KFM 1.4 released

It’s been almost a full year since the last release, 1.3.1, and I haven’t done much on KFM in that time.

Benjamin ter Kuile, though, has! Today, we release KFM 1.4

In the time that I’ve been busy with other stuff, and procrastinating on KFM, Benjamin has been working diligently, adding features and making the core files more stable.

Here is a short list of improvements, gleaned from the SVN logs over the last year. I’m sure I’m missing a lot.

  • jQuery upgraded to 1.3.2 (faster, better, stronger)
  • you can edit multiple text files simultaneously
  • context menu code improved to help it work in Chrome, Opera and Safari
  • file icons are now created as a montage, improving display speed
  • a lot of functions converted to “lazyload” – improves startup speed
  • images are also lazyloaded – if an icon is not visible on the screen, its thumbnail is not loaded
  • lots of bug-fixes

Not many new features, as KFM was basically complete.

1.4 is the last 1.x version which will be released. We’re done with the code-base, and ready to start on a much more ambitious project.

We’re going to rebuilt the entire system from scratch in a modular way, adding functionality that would be very difficult to shoehorn into the present system. The new version will be called KFM 2, and I’m really excited about it. I will be starting the coding for it very soon, as soon as I’ve finished with the release of my book, jQuery 1.3 with PHP.

For those of you that are already using 1.3; 1.4 is /faster/, but 1.3 already completes the initial spec, so only upgrade if you find that 1.3 is slow. New users should install 1.4.

grade 1 piano results

Last week, I went to Dublin to attend the OSS BarCamp in DIT, and to meet up with friends and to do a piano exam.

Bronwyn and myself have been learning piano for a few months, and I wanted to have some evidence that I was progressing.

piano exam results

I was nervous going in. In the exam, what happens is that you play a few scales and other little things, you play 3 songs from a selection of 8, and then you answer some questions.

The major scales were pretty easy – I was asked to play a few major scales, only one octave, and only one hand. Wasn’t asked to use the left hand at all.

I started out on the minors a bit wrong – the examiner asked my to play “A Minor Harmonic”, and I accidentally played “A Minor Melodic” (the difference is that the leading note, before the tonic, is sharp when ascending and natural when descending, in Melodic, and sharp in both directions in Harmonic).

I apologised and played the requested version. To be honest, I think the examiner made a mistake there, because the examinee is supposed to play /either/ harmonic or melodic, personal choice.

I made another mistake when asked to play triads. A triad is a group of arpeggios which start on a different note of the chord each time. For example, C triad is C E G E G A G A C A G A G E G E C. But, my teacher learned in the London School of Music, and the triads I learned ended on the dominant note – C E G E G A G A C A C A G A G E G E C G.

I corrected myself there as well. These were honest mistakes, but I think knowing the difference and being able to play them, helped with the score.

I had chosen three songs to play.

First, I played Menuet in F, by Leopold Mozart. I really like this piece – it’s light and airy, and there are a few stacatto bits that really fit well into the rhythm of it. I fumbled a bit on the first arpeggio, and wasn’t able to get the dynamics correct on the piano – the piano sounded weird compared to my own (tinny, maybe), and the keys didn’t have much “feel” to them – pressing the keys, I didn’t feel any “power” under them. Very hard to do piano forte when you can’t feel the difference between piano and forte ;-).

The second song, a waltz by Breslaur (Op. 46, No. 25), went perfectly – that’s another airy one, and I tried to play it as if it was being danced to, not as if it was being examined. Again, the dynamics were difficult to put n, but the fact that is a dance, and had a load of stacatto to it, helped get around that problem.

The third song, Study No. 1 by Felix Le Couppey, wasn’t too good. I chose this song because it was totally different in feel to the others – this was going to be the one that showed off the dynamics. I really should have practiced it on a few different pianos, so I knew how to approach the exam one.

I’ve been beating myself up all week over these mistakes, so was very surprised to find I’d passed the exam, “with first class honours”.

Yay me!

I’m choosing songs now for grade 2.

jQuery 1.3 With PHP: cover mockup

6989_MockupCover

I’ve been sent a mockup for the book’s cover. The suggested title of the book is “jQuery 1.3 with PHP”. The working title was “PHP and jQuery”. Which do you prefer?

The book has been completed, in that all the chapters are written, and it’s in the final edit phase at the moment. This involves Packt having a technical editor try everything in the book just to iron out any kinks. It’s already been gone over by three other reviewers, and the only problem appears to have been with the File Management chapter, where the web-server was IIS on Windows. That should be solved by the time the book comes out.

I’ve learned a lot while writing this book. A major point that keeps raising its head is that I keep using colloquialisms and aphorisms (ha! “raising its head”), and those are not globally understood. Another is that I keep using British spelling, but it’s expected that most readers will be American.

From a coding point of view, I tend to write compact code with comments only appearing where something is obviously confusing, but I’ve tried to put proper comments in the book whenever any reviewer asked a question about the code.

Anyway – I expect it will be in PDF form in only a few weeks! I’m looking forward to hearing what people think of it.

On a funny note, I was working on something in work recently, and was trying to figure the best way to do it, when I suddenly remembered I’d written a whole chapter on it, so went and read what I’d written! I’ll be keeping a copy of the book on my own shelf 😉

This kind of thing is always happening to me – I would need to solve some problem (hooking an OKI B2200 printer to Linux over Samba, for example), go searching for the answer, and find that I’d written the solution for it a year or two previously…

By the way, KFM 1.4 will be released next week. It will be the last 1.x version. We (Benjamin and myself) are starting a total rewrite after that, which will become KFM 2. It’s going to be massive!

EDIT: 2009-09-18 Wow, that was quick! The book is already available to pre-book