back in the saddle

So, finally getting some solid work done again. The last few months have been crazy, with deaths, family visits, holidays and pretty much any other distraction one could imagine (well, not so much perhaps... no itinerant see monsters destroyed the city for example, though a gas company did blow a small part of it up)

So, the long suffering MB code has been pulled apart and is approaching being put back together again in some kind of working fashion. All the stuff that deals with the business of asking a remote service a question and getting back an answer has been pulled out into a separate code base which should actually come in pretty handy for any type of web service or other remote query scenario.

Having finally read the gang of four's design patterns book is a good thing. The patterns themselves are very handy but the biggest benefit is the perspective that thinking about such issues grants.

A universal backend (not a J-Lo joke)

I've started to keep track of my own (as in, not work) projects in kplato. In general, as a project scheduler it seems to compare really well with the other software of its kind of used and of course integrates nicely with the environment. There are a couple of usability issues for the way I seem to want to use it, but nothing earth shaking. Were I a better person, I'd have made notes and passed them... I'll have to try and remember to do that next time I set up a new project.

Also, like most examples of this kind of software, they provide way more features by default than I use on a small to mid-size project, especially one where I'm my own boss and I don't really care about or can't really use features like multiple resources working set hours a week at such-and-such an hourly rate. I'm really just using it for a nice tree structured TODO list in some respects, with the ability to record when things are completed. It would suit the way I use it at present to be able to have a new project template that started a default project with the just the bare minimum of fields displayed and little to no resource monitoring. Kplato supports templates, so I'm sure something like this is probably quite possible.

Anyways, what this got me thinking about was two things really. One, it would be cool to have a multi-user version where the data is all stored centrally and clients connect, read from and write to that central copy, have access to a global resource list so that resource allocation for an entire work group could be calculated and reported across all the existing projects and inter-project linking could be more powerful.

The other thing that this got me thinking about was: it would be cool to have a global backend for applications that commonly store numerous versions of their documents. You could define an API that any application that wanted to could use to write data off to a global store. The API could support a number of operations like storing diffs, time stamping, encrypting and all the other things that storing versioned data requires as well as offering a bunch of other cool things:

• It could use pluggable backends so any given user scenario, hardware combination and storage technology available could be used. For example, it could support flat files, SQL databases, existing version control systems like subversion or even file systems like ZFS.
• It could also provide a pluggable interface for compression and encryption. As new technologies come along that provide better / faster / sexier compression or as crypto systems get defeated, new versions could be plugged in
• You could do cool time machine stuff like a certain fruit moniker-ed company's OS
• You could have a backup daemon that could, again, support plug-ins for different archiving methods
• It could automatically generate nepomuk data
• You could have a KIO slave provided file system style access to your documents
• As well as integration into content generation and manipulation applications, programs like dolphin and konqueror could let you browse your archives.

Applications that this would automatically be cool for would be all of koffice, digikam and gwenview, kdevelop, kate and all the content creators and editors in KDE in general.

Applications that might not be as obvious but could also be interesting include network communications tools like kopete and konversation. For applications like these, it wouldn't be so much be about keeping version data as once it's on the internet there probably isn't as much use in reviewing version history as their might be for a word processor document for example, but it would be good to be able to have chronological browsing.

First Post!!!1!

So indeed, this is my first blog post. I'm sure this will seem like a pretty lame entry when archaeologists uncover our ancient internets and read this blog (after all, they'll have so much free time between jet packing to the store and dropping the kids off in the flying car thanks to the friendly robot work force).

So why start a blog?
< long pause \ >
well I guess at least theoretically to have someone read it. Hopefully that (those?) someone(s) will be moved to leave a comment and from there, discussion could ensue. So I guess really what I want to use this for is an opt-in way of starting discussions rather than spamming newsgroups or other peoples blogs. I may also occasionally rant, just because it is the internet after all.

So the next question is, what to blog about? I think I'll try and keep this mostly technical. KDE and related adventures in coding and perhaps occasionally PHP and work related stuff, if something interesting comes up (or I feel a need to rant on DICOM and how much I am not a fan of it).

So, I think that'll do as far as first posts go. I don't suppose anyone beyond myself is likely to read this post at least, but thats probably a good thing, it can just serve as a little reference for me in the future, plus you gotta start somewhere and there does not seem to be any elegant way to ever make a start at a public endeavor.