[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[coldsync-hackers] p5-palm
Hello,
I've been looking at the Palm::PDB file, and I'd like to suggest
a bit of a change.
Right now Palm::PDB is "smart" and supposedly knows which handler
to use. And calls the correct one based on the creator/type pair
when loading a database. However, I find this annoying.
Especially if I don't know the creator/type, etc. When I tell it
to load a file, I want it to load the file i say, using the
Palm::Whatever class i've derived from Palm::PDB. I dont want it to
go and use some other handler.
What i'd like to propose is a new object:
Palm::Manager (or Palm::PDB::Manager or ??? )
Whose purpose would be to call the correct parser for a randomly
given PDB/PRC database.
For the Manager, it'd be a cool thing if we could make it "smart",
and be able to try to load a package with the correct code for
handling a database. Perhaps a file with creator/type and perl
module for handling that database could be kept. Perhaps doing
it manually makes sense.
I would suggest that Palm::PDB be a "simple" class for reading in
and writing PDB/PRC files. (Would it even make sense to make
classes like: Palm::DB_File, Palm::PDB, Palm::PRC? It makes sense
in an Object-Oriented mindset, not neccessarily practical.)
So, the base Palm::PDB would be used something like this:
my $foo = load Palm::PDB("file"); ## or
my $bar = new Palm::PDB;
And have basic functions -- like adding/accessing/removing records,
modifying flags, etc.
Then, for each application PDB, it inherrits the Palm::PDB.
For example the Visor::Eyemodule would inherit the Palm::PDB and
when I say 'load Visor::Eyemodule("/path/to/pdb")' it reads the
specified file.
Here is an other of my ideas. It would be nice to be able to
specify the format of each record. For example, each eyemodule
database record has a format like:
type var_name
byte[32] name
byte version
byte type
ulong firstVGARecUID
ulong noteUID
Word lastPosX
... ...
Anyways, its real tedious for me to have to go and parse each record
manually, makes for errors, pain in ass, etc... It'd be really cool
if I could just define the record schema, and whenever I ask for
a record, it'd give me a hash (or even an object ?!?) with the
approriate info. (still w/ accessors for raw-data).
One last idea, although I'm not sure if it is a good idea or not.
There seems to be a bit of an overlap between the manager/pdb and the
ColdSync conduit. Perhaps the default conduit behaviour could be
defined by the base Palm::PDB class, and if more functionality
was wanted, sub-classes could define it. It seems to bring a fairly
nice closure to it. But then again, it ties the conduit behaviour to
the PDB manager behaviour. It might feel imposing to programmers or
users to a single conduit solution instead of doing what they want.
For example, if the Palm::PDB::Mail had its conduit doing one thing,
people may not write a better one b/c there is one already exists.
I'm sorry if i'm not entirely coherent. English and I don't always
get a long very well.
Ryan
--
Ryan VanderBijl http://www.calvin.edu/~rvbijl39
--
This message was sent through the coldsync-hackers mailing list. To remove
yourself from this mailing list, send a message to majordomo@thedotin.net
with the words "unsubscribe coldsync-hackers" in the message body. For more
information on Coldsync, send mail to coldsync-hackers-owner@thedotin.net.