Unterwegs Reloaded

Well, i was struggling since 2003 thinking about a mobile tool which could find routes for local public transport. Nowadays this problem isn't yet completely covered and there are no clear solution for this. The idea has also evolved, now an internet based search engine for PT is required. Key feature is application of the 'matrjoshka' concept for nodes. The algorithm should work in two steps: 1) find all possible (applicable) paths, 2) calculate times and offer more convenient routes. The second step is optional. This should be a big boooom.

Jiista Project

It's a 'phone' concept, screen is the whole body, front and back. Back light (blooming) goes through the whole phone and has different colors (can produce any color). No speaker holes. No holes.

Karapet's Application

One possible application of Karapet's application is described in the article "Vehicle warning system trialled". Generally speaking, there should be a message/event signaling system. A third-party service could subscribe to an event or create it's own event. Probably we will require hard-coded (pre-defined) event classes or categories. More study on the OSGi framework is required, what will be performed on the next week. This week the homepage should be defined.

Finally a bright idea

Carrying about recent domestic problems I was quiet uninvolved in the development process. If not this mail from one guy yesterday... He asks if he could use Keep Bluechattin' for chatting between two devices via a dedicated channel, thus using a self-created service. This is something I was planning for Karapet and what was not thought for Keep Bluechattin'. Well, at this moment there are dozen of proprietary Bluetooth chat tools which provide this, and even more of them to come. What's the problem with all of them, why none is getting wide acceptance on the market? There are some reasons:

1. Authors of these tools are greedy, very seldom you can get such a tool for free.
   
2. They all trying to use their own channels/services, so you have to have the same software on both ends. And their 'protocols' are not open.
3. All services are hard-coded and not extendable.
4. They often have poor platform support (e.g. only .NET CF 2.0 & MSBT-stack).

So, there is an emerging market. We are so far and there hundreds of gadgets which support (more or less) either .NET CF or MIDP platform and have Bluetooth/IrDA/Wi-Fi interfaces.

This is the right time for Karapet. Karapet is a mobile services platform, which provides among other things a service registry/directory. It's very scalable and has very little overhead. The core system is lightweight and fast.

To support wide range of Windows Mobile devices, it is build on top of the .NET CF 1.0. It will support following networking services: Bluetooth, IrDA, Wi-Fi and GSM/GPRS.

So, today I got the idea that Karapet concept is something very similar I've already seen in OSGi, moreover in it's .NET CF implementation attempt - Physalis. So, let's go for Physalis and see whether we can reuse something from it to complete the Karapet concept and core.

Another idea is that interface between separate Karapet-enabled devices should be universal for .NET and Java platforms.