An example of the extensibility of the idea is shown to the left:

Simply by creating directories containing the years, months or dates (or any combination e.g. quarters, you can create any directory structure up to any level you want…it’s your harddisk ) you can create an agenda which you can maintain via notepad or vi…

Another advantage is that you can reuse the field plugins in the info.txt files in the folders e.g. a “date.meeting” will be handled by the same plugin. You can add any fields you want  to the days.

Another advantage is that you can copy files in the folders of the e.g. days so you can keep track of the stuff you produce on a day in a date order if that’s of any use and later browse or report on it by simply copying the files in the correct directory e.g. 2007/Januari/15!

You could also create “work agenda” and “private agenda” directory and then let different report plugins handle either the combined dates or the dates of the seperate directory structures.

Simple isn’t it?

You can even drag contacts on a date and then let a directory-handler plugin determine if e.g. the plugin should be added to this date e.g. for a meeting and then popup a dialog.

The last idea makes me rethink the single directory tree structure. Maybe a split screen is handier or a screen where a tree structure is shown in the left and then 2 windows side-by-side for copy and paste actions (like in Total Commander).

Another thing which would be handy is if I could drag a contact on a directory and the directory would know what to do.

E.g. to the left I could drag “Bob Janssen” to the folder “linkedin.social” and it would create a directory Bob Janssen in the Linkedin Folder and even popup a screen where it would ask me the crucial linkedin data to populate in the info.txt file which is placed in the /hyves.social/Bob Janssen/info.txt (e.g. “invited or member”, “linkedin url”, etc…)

In this way it could be a very quick way to add members to a social network directory.

Some other ideas:

- If the info.txt in Bob Janssens directory contains the field “linkedin” and Bob Janssen is not yet in the linkedin folder it could place Bob there automatically after finding this out, this would make life easier.

- The linkedin Bob Janssen folder’s info.txt would contain a field called “link” which links to the other bits of profile data of Bob around the directory structure. In this way all the profile datas could be combined to see a master profile of Bob. I imagina some tabs where each tab is defined by a report plugin e.g. only contact data tab, full data tab, badminton club information, rss feeds, attachments, etc…

- other files in Bob’s folder could be previewed e.d. word documents, spreadsheets, photographs, urls, rss feeds etc…

Obviously when it works, this application can be used for pretty much everything: bookmarks, recipes, collections, etc… since everything is pluggable on directory, field and report level. It can be a one-stop full life information system.

I’m building a fully text based address book in php while Blogging

The next thing I want to build in my addressbook is a handy calender.

It means however, for now, traversing through all directories on disk and retrieving all dates to put in an array wherafter to display them. There are some things in my mind:

- I could put each plugin field e.g. BIRTHDAY in a hierarchy which I would somehow make OO so to say the plugin BIRTHDAY would inherit properties from the general defined object DATE which would be some kind of superplugin dataformat. Which is a bit unflexible since there will be formats the user wants to add on the fly by just editing a simple textfile (and later on report on it). So…I could also make the decision to require a date to be “DATE__birthday = 16-06-1971″. In this way someone could simply add a line called “DATE__pokergame = 23-03-2008″ and the date will be in the calender with as type “pokergame”. The calender could then have a checkbox list with all the different types on dates it finds to dynamically show them in the calender. The user could also write specific reports depending on the types he adds on the fly. Another advantage would be that he could add just “COLOR__red = likes it” and he could later on write a report to show all people who like all different colors without someone creating a superobject COLOR in the first place. I have the think about the __ maybe that’s not the best characterstring to indicate an object grouping hmmm why dont I just use a dot? “date.birthday = 16.06.1971″ seems logical. Hmmm I could even add an hierarchy of dots “color.red.like = yes” which could show anything someone likes hmmm… I could even use it for the social network information: “tv-serie.lost.like = yes” so I could filter all tv series in the data set.
The most important thing is that someone who edits a text file is not bounded to too much rules.

- I also need to add functionality so the user can flag fields that should not popup in the calender (e.g. death date)

- Because traversing through filestructures and reading all seperate files takes time I have to think about some kind of caching scheme, maybe in a disk based database structure purely for caching it has to register when files have changed on startup to refresh the cache.

I decided to make leaves, like contacts, also directories. Every directory now contains a file called “info.txt” which in a very simple form contains the essential data of the object. E.g.above you see the core information for the household “Bob and Marie Janssen”.

Every contact is also a directory which enables me to store photographs, (todo) lists, e-mails and other files concerning the contact “inside” the contact itself.

The next to think about is the format in which my addressbook files are stored.

When I click on the directory “household Bob and Mary” it probably will have a general text file (holding the general data), a text file describing Bob and a text file describing Mary. Obviously they will hold relations to each other.

I could choose some XML format, JSON format, wiki format, html format or some configuration file alike text files, all would have their advantages and disadvantages. Primarily it should be easy for the user to edit a text file and add e.g. “haircolor” to a contact. But it should also be easy to create a birthday calender which would scan for all date types (e.g. anniversaries on household level and birthdays on contact level), so the contact should be semantically easy to parse.

Intuitively I would discard XML and JSON because users would find it too dificult to enter data to it. Wiki format may be a possibility  which would have as advantage that I could somehow integrate it with e.g. dokuwiki in a later phase. It would also allow the user to use specific wiki tags to format the content. However, the part of getting all dates of this file would be somewhat more difficult.

Maybe I should just start with simple text files with each line containing the field, an equal sign followed by the value. I can make things more complex in a next phase.

Using the PHP Jquery file Tree from Cory S.N. LaViska I saved a lot time. I modified it so that directories also become clickable and have their own icons and then changed the alert call to a JSON call to my report.php.

The next step is simple: just let report.php handle the type of item clicked. E.g. on a household display all contacts in the household.