Re: [coldsync-hackers] p5-palm

[Ryan VanderBijl <rvbijl39@calvin.edu>]

Hello,

> > 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 think i miscommunicated. I never meant to suggest that any of the
functionality was missing. I just think that the functionality is,
perhaps, in the wrong place -- if that makes any sense? For example,
the Palm::PDB  seems like it should be a relatively simple thing --
read's in a given file, etc.  It doesn't seem to need to need any 
smarts of how to handle the various creator/type matching.  When I
first tried using it, i didn't expect that, and it bothered me.

Especially because the pdb files which I got off the visor were under
different creator/types than what was documented! :-( So that took
a little (lot) of time to debug.

Basically I'm just suggesting a "concept" change -- which very well
may be too late. I want to keep all the functionality, just move
it's location from Palm::PDB to Palm::[DB::]Manager. It seems to make
more sense from a basic point of view, and from an object-oriented
point of view.


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

So what kind of structure would the Palm::PRC have. If you say that
the Palm::PRC files are fairly different that ::PDB, then I definitely
think that a Palm::PRC should be made. What other functionality would
be common for a PRC file?

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

Yeah! I figured if I gave enough ideas, at least one would be good ;-)

I'd  love to implement this. However, don't hold your breath. I have
a bout 3 other projects for school/work which i need to work on.

Maybe i'll take a look-see at rpcgen though. 

Thanks,

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.