Re: [pilot-db-list] editing on a PC

[Nathan K. <na...@ve...>]

> > > Should it? Is this a good way, considering no tool will follow closely
> > > enough the development of pilot-db? And, BTW, isn't something written in
> > > some higher-level language easier to write? E.g. things like
> > > datascript or DataWorkshop? I know this isn't pilot-db-related, but
> > > palm-db-tools seems dead to me.
> > 
> > We've had a bit of discussion this list about what needs to be done
> > about this, but no solution yet.  I wouldn't give up on the hope of
> 
> I will read the archives.

It was probably sometime in January, and it was only initial discussion.
I wasn't trying to imply that it should not be discussed further!

> > having a tool that would follow the development of pilot-db.  In fact,
> > I think that is just about the only hope.  
> 
> Generally speaking, I agree. But this wasn't my point. What I wanted to
> say is this: Even though there is currently no tool that knows about
> recent additions (global scripts, filters), there is still a way to
> edit the _data_ part without loosing all the metadata. Using only
> palm-db-tools, pdb2csv and csv2pdb, this isn't possible - on the first
> conversion you loose everything not supported by it. Using par, I keep
> all the metadata in binary form, as a single appinfo file, and edit the
> data with whatever I want.

Yes, certainly a tool that did not throw away all the information it
did not understand would be a useful improvement.  I must confess I
haven't actually tried using palm-db-tools in the last couple years. :(

> But when writing for a PC, we can use some higher level language. Either
> a general-purpose scripting language (such as perl or python),

Yes, definitely.  I think the best way to achieve this might be to
have a C language library that allows access to PDB files (ideally one
that actually shares most of its code with the Palm version), and then
write some interfaces to this from Perl, Python, etc.  But just doing
it directly in some other language would be fine too.

At this point, we could happily benefit from anything that works.

> is what I suggested, to use a tool that is specifically intended for such
> a thing - a tool in which you define your data in some language and can
> automatically edit or export/import it, without adding code in a lower
> level language.

Sadly, I fear what we really need is just a good definition of our
data format.  Currently, there does not seem to be one other than as
defined by the current C code.    

--nate