The plan had been to code this in Java. Then after talking with many genius folks at OSCON more options are looking possible.. The main candidates for the language this will be written in are:
- Embedded perl (using
par)
wxWidgets
- Template::Extract
- Microformats
- Something to synchronize
- Python + Python xw
- Java
Metadata, microformats, and data
conversion
How do we store the content and data on your
local machine?
- The MoveMyData tool will support many types of content:
This is not just a solution for one type of content. This will be a
solution for many types of content. Once we have the basic content
types in
the system, we'll continue expanding. As new sites pop up with new
types of content and metadata, we'll expand the support and formats to
work for those also.
- Types of content we'll support at first: The system will be built to support images, writing, peoples profiles, blog entries, video, and more. For each content type, there can be tags and comments. For peoples profiles there can be testimonials.
-
Every type of content has a microformat it's
stored in: For each type of content we support, we'll have a standard
XML format for storing and naming data about that particular type of
content. On a persons local machine, all data downloaded with the
MoveMyData tool will be stored in this format. Note that this
encourages other local applications to also make use of this data.
We should also be looking at RDF when determining how we store data.- Determining the microformats to use: We're not looking to reinvent where it's not necessary. If an XML format for storing a particular type of content already exists we'll use it. If a format has adoption already, it makes it that much more appealing. For more on possible existing formats, look at MicroFormats.org
- Store the content data in the content: The tags and other metadata for an image will be stored in an image itself. This makes it easy to move the image and have the metadata follow automatically.
- Data conversion: Each community content site will have a different API and different names and formats for how it uses and provides data. We will convert each of these data formats into one universal consistent format. Then when the data is exported to other sites, it will again be converted to fit the format or API for that site.
