Re: [coldsync-hackers] p5-palm

[Andrew Arensburger <arensb+CShackers@ooblick.com>]

On Sun, 29 Oct 2000, Ryan VanderBijl wrote:
> 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. 

	The simple fix is to add

	package MyClass;
	sub import
	{
		&Palm::PDB::RegisterPDBHandlers(__PACKAGE__, "");
	}

to your package. That'll register MyClass as the default handler for
all (record) databases.

	I'm not sure what you mean by "Especially if I don't know the
creator/type, etc." If you're writing a parser for, say, TealPaint
databases, then presumably you should find out the creator and type of
its databases, otherwise a user will inevitably give you a MemoDB.pdb
as input, and your parser will never notice.
	If you want your script to work with any kind of database
(e.g., you just want to count the number of records in a database),
then just use wildcards in RegisterPDBHandlers. See Palm::PDB(1) for
details.

> 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.

	This sounds nifty in principle, but I'm not sure how much use
there is for it (other than something like 'pdbdump'). I suspect that
99% of the time, the script's author knows what kind of databases ve
intends to deal with.
	If you want to handle the other 1%, my suggestion would be to
turn %Palm::PDB::PDBHandlers into a tied hash. I think you'd only need
to supply FETCH and STORE methods. See Palm/PDB.pm for details.

> I would suggest that Palm::PDB be a "simple" class for reading in
> and writing PDB/PRC files.

	You may be thinking of Palm::Raw.

> (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.)

	Palm::PRC would be a Good Thing, but would be almost
completely different from the way PDBs are handled: in a PDB, all
records are of the same type. In a PRC, however, you can have all
sorts of resources of different types. Hence, with PDBs, it makes
sense to have a parser for "TealPaint databases", whereas with PRCs,
it makes sense to have a parser for "all bitmaps, regardless of the
PRC they appear in".

> 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).

	Yup. I'd been thinking recently that it would be nice to have
a utility like this. Freshmeat and SourceForge don't have what I want,
though. If you decide to write this, my suggestion would be to look at
'rpcgen' and adapt it, rather than starting from scratch.

-- 
Andrew Arensburger                      This message *does* represent the
arensb@ooblick.com			views of ooblick.com
	You are validating my inherent mistrust of strangers.


-- 
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.