dkessler
Member
Registered: Jul 2000
Location: Plant City, FL
Posts: 385 |
quote:
Originally posted by PiDeveloper
Maybe Dave or anyone from kopsis can give us more clear explaination will their VFS support able to access databases directly without modified the origianl application available on the market and/or the applications should be VFS awared.
I really wish there was a good way to cut through all the confusion. I know that this stuff is all very technical and that makes it difficult to give a concise explanation. So at the risk of sounding long-winded, I'm going to try and explain a little more about how all this stuff works ...
I think we've established that for the CPU on the Visor to run code or see data, that code or data must be in directly addressable memory. That memory can be RAM or Flash like the HS 8MB Flash module has in it. That memory can not be a CF/SM/SD card. So, that means that if your data or apps are on a memory card, there must be some way to get them into RAM. Everyone still with me? Good 
Now, when stuff is in RAM, the operating system (PalmOS) has to have a way to keep track of it all. So the PalmOS, ever since its earliest versions, has had a set of functions for accessing code and data that is stored in RAM. There are a lot of these functions and I won't try to explain what they all do. But in general terms, when you ask the OS to run an application the OS calls some of these functions to locate the code and "lock" it to a certain place in RAM. When a running application wants some data from one of its databases, the application calls those functions to "lock" the data to a certain place in RAM.
What PiDirect (and AutoCF and MSMount) all do is "intercept" all of those operating system functions that deal with keeping track of the databases and applications in RAM. So lets say an application uses the function that finds a database in RAM. PiDirect "sees" that request and also looks for that database on the memory card. The application doesn't know PiDirect is doing this. It just knows that the database was found and assumes that it must be in RAM. Later the application uses an OS function to read a record out of that database. PiDirect again "sees" that request. This time PiDirect goes through the file on the memory card, locates the record that was requested, copies that record to RAM and tells the application where to find it. The application doesn't know that this just happened. All it knows is that it asked where a particular record was and the "system" found it. I hope I'm making sense so far
Now, running an application is not much different. In that case the OS is using its own functions to find out the location in RAM of the application's code so it can run it. PiDirect again "sees" those requests and copies the application's code from memory card to RAM and then tells the OS where it is. The OS doesn't know that this happened and in most cases, it doesn't care. All it knows is that it found a place in RAM that has the code it wants to run.
That's PiDirect (and AutoCF and MSMount) in a nutshell. The good thing about it is that neither the OS nor the applications have to "know" anything about memory cards. They get to keep on assuming that all their stuff is in RAM and when they ask for it, PiDirect puts it there. This means that pretty much any application, no matter how old and out of date can use the memory card to store its data. The down side is that the stuff on the memory card is treated as "read only". Applications can't write anything to the databases on the memory card.
There are other drawbacks to the PiDirect technique. The OS functions for accessing data were designed to work really well when the data is always in RAM but because of that applications using those functions often make bad assumptions about how easly they can get to the data they want. For example, Mapopolis databases have most of their data piled into one huge record. The application may only need a small chunk of that data, but because there's no way to know which chunk it needs, the entire record (which ends up being almost the whole database) has to be copied to RAM. The file format that Palm databases are stored in is also very inefficient for locating records quickly. It was designed to make it easy to move entire database from one system to another quickly and easily and not for efficient random access.
When Palm wanted to add SD support to their PDAs, they recognized these limitations and created the VFS Manager. The VFS Manager is, in many ways, much simpler (and some would even say less sophisticated) than PiDirect. The way VFS works is that instead of using the same set of functions to access RAM and memory cards, VFS adds a whole new set of functions that are completely memory card specific. If an application wants to get data from RAM it calls the RAM access functions. If it wants to get data from a memory card, it calls the VFS functions. The VFS functions ultimately copy the data to RAM, but now the application can have more control over what data it gets. The application doesn't even have to keep its data in Palm database format. It can use whatever form is most efficient for the task at hand. The application also has the ability to write data to the memory card making data on the card no longer read-only.
But every silver lining has a dark cloud. In order for an application to use the VFS functions, it must know about them. And right now the majority of Palm applications don't. If an application doesn't know about VFS, then it can't get its data off the memory card (without some additional help). But Palm, being the proverbial 300 pound gorrilla of the PDA world decided that's ok. They know that lots of people will buy m500/m505 PDAs and those users will want applications that can use the SD card. At the same time, Sony and HandEra have adapter VFS as the way for apps to use the MemoryStick and the CF/SD cards on those devices. Developers can either ignore those users, or scramble to release new versions of their applications with VFS support. Lately there's been a whole lot of scrambling going on
Confused yet? Don't feel bad. It gets even more complicated when you take into account MSMount - a PiDirect type application that runs on top of VFS. And there's also PowerRUN - a VFS application that will move an application and it's databases back and forth between RAM and a memory card automatically.
Which solution is right for you? That's your decision. Obviously Kopsis thinks that an Innopocket or Matchbook adapter with VFS is the best answer. PIT naturally thinks that a MemPlug with PiDirect is the way to go. Here are some basic guidelines:
1) If you have a Visor Solo or Visor Deluxe you can't use PiDirect. You can use VFS. However there are several applications (including LauncherIII) with native MemPlug support and those apps will work pretty much the same as they do on a VFS enabled system.
2) If you primarily use old or existing applications and don't want to have to worry about getting new VFS compatible versions, then a PiDirect solution may be the best way for you to go.
3) If you're more concerned about running new (or new versions of existing) applications, then you should strongly consider VFS.
4) If you're on a budget, you can get a Matchbook drive with VFS for less than half the price of a MemPlug
5) You can count on things changing on almost a daily basis. PIT has promised they will have VFS support in the future and Kopsis is busily trying to make MSMount (which provides the exact same functionality as PiDirect) work with our software.
Factor in things like innovation and customer support and things may get even less clear The bottom line is that choosing between a couple of really cool products is always hard ... but hopefully this information will lift the fog a little bit an make it easier to make an informed decision.
__________________
<ul><li>Dave Kessler<br>President - Kopsis, Inc.</li></ul>
|
06-28-2001 02:46 PM
Email This Page to Someone! |
Receive updates to this thread
]