 | ||||||||||||||||||||||
|
Plan de campagneThe protocol used by Epoc 6 devices to communicate with a PC is not open. Fortunately somebody depicted this protocol for Epoc 5 devices. I have a Nokia 9210, so at this moment that is the only device I'm going to try to make accessable under Linux. To do this I need to understand the protocol, see the differences with the older version of the protocol. (I will email the differences to the writer of the protocol document).So this is the plan: -1- Make components used by the analyzer and the actual LinPoch suite -2- Build a Analyzer tool to understand the protocol -3- Analyze the protocol as used with the Nokia 9210 Build the 4 layers (rs232, link, session and presentation layer) with minimum requirements: -4- which simple connection with the device (link symbol on the device visable) -5- not being able to disconnect propaly -6- not being able to plug-in a different variant of the protocol (a different device than the Nokia 9210) -7- try to send a command (something like send me your version number) -8- extend the presentation layer with more commands -9- think about how to connect with KDE's koislaves (plugin for Konqueror), maybe something with DCOP -10- Choose a interprocess protocol and implement it -11- think about GCJ (native Java compiler), maybe KDE needs to be compiled with gcc 3.x -12- extend the presentation layer with other funcationity, e.g. contact sync, or make a installer for .sis files (more fun to do!) -13- Bad number, figure out what point 14 could be. StatusAnalyzing the protocol will never be completly done I guess(-3-). But the main issues are dealth with. I used the analyzer tool to analyze the protocol(-2-). The tool is complete enough for me. The tool delivered some components to the rs232 and the link layer) (-1-)The rs232 and the link layer are getting pretty mature. A simple program using these 2 layers is able to do a simple connect(-4-). Today, 12-05-2002, I'm able to send a simple command (querry drives) and getting a response, so that means -7- is accomplished. I've finished the session and presentaion layer. The presentation layer has some extra commands. (-8-) To make the files from the Epoc device visible in Konqueror, I must write a so called ioslave. This slave runs in konqueror, and it has to communicate with the software that handels the actual communication. This software runs in a other system process. This process is has a small gui, visible in the systemtray of KDE. From a KDE perspective, the natural thing to use is DCOP. DCOP is a framework which is part of KDE and enables communication between desktop processes. Unfortunatally, with the current java-kdebindings, DCOP-java is incomplete. At the moment I'm lokking how I can extend the bindings, and it looks good. If this DCOP-java stuff succeeds, I have to contact the kdejava maintainer, and ask if he can put my additions in the current CVS of KDE. If this DCOP-java stuff fails, I have to look at something like mico. After this interprocess (one way or the other) is finished, I'll develop LinPoch to something usefull and make a distrobution release of it. At the same time I can test it and fix bugs. DCOP interprocess with Java -> C++ works! LinPoch offers a DCOPObject. A KIOSlave (konqueror plugin) written in C++ makes use of this DCOPObject. I'll have to take a little more care of the additions to kdejava, they currently don't release resources... After a time the writer and maintainer is back. I've got cvs access to the kde sources, I'm planning to act as a backup. This way LinPoch and other kdejava application continue to work in later versions of KDE. Right now I'm helping him a little bit. I'm extending the kdejava bindings with my additions, so other Java / KDE developers can use it too. The development of that dosn't affect linpoch. When KDE 3.1 is out I'll make a release of LinPoch. With this release it is possible to do the following with files on the Nokia with konqueror: - list directories - copy files - delete files - rename files |
|||||||||||||||||||||
