Actually, after reading the gdbm example programs it looks like gdbm itself is just
like a perl hash. The interface to gdbm is very simple. Here's an example, sans error
checking:
GDBM_FILE pfile = gdbm_open("tstgdbm", 512, GDBM_WRCREAT, 00664, 0);
datum key = {"foo", strlen("foo")+1};
datum val = {"bar", strlen("bar")+1};
gdbm_store(pfile, key, val, GDBM_INSERT);
If we choose to use gdbm, I think there just needs to be a way to map our data into
key-value pairs. Maybe it would be helpful to use more than one gdbm database? I'm no
PIM expert, but maybe the database could be indexed by date, and the value could
contain the appointments/todo items for that date. Since this 'datum' data type has a
separate length parameter, it looks like structures rather than strings could be used
as keys or values.
On Wed, 08 August 2001, John Utz wrote:
>
> i think i can suggest a direction to pursue that would work around the
> deficieny that you pointed out wrt to hierarchical data and gdbm:
>
> perl has a TiedHash (or something) module that maps perl hashes to gdbm.
>
> for non-perloids, a hash in perl is a marvelous data structure ( or lack
> thereof :-) ) that aloows you to map arbitrary data to arbitray data.
>
> we could rip out the vital bits from the c code for Tied Hash that maps
> the hashes to gdbm and use that. I suspect that it is basically a Symphony
> In Indirection :-)
>
> On 7 Aug 2001, Micah Dowty wrote:
>
> > I agree. XML and vCalendar both have their shortcomings: XML is bulky, and
>vCalendar isn't flexible.
> >
> > I took a look at the latest gdbm release. It's 5589 lines of C (not including
>headers) which compiles to a 31867-byte libgdbm.so on PowerPC. It should be similar
>size on MIPS, and smaller on x86 and m68k. The documentation also says it has no
>arbitrary limits on data size.
> >
> > Looks like gdbm for local storage, and import/export to XML and vCalendar could be
>a good solution. gdbm works like Perl's hashes, pairing string keys with string
>values. We'd have to figure out how to represent the calendar data as keys and
>values. It seems like a hierarchial format would be more useful though. We need
>something with the structure of XML and speed of gdbm :)
> >
> > On Tue, 07 August 2001, John Utz wrote:
> >
> > >
> > > hello
> > >
> > > i'd suggest that Tasnim is on the right track wrt to the storage medium on
> > > the device.
> > >
> > > but, i think the problem needs to be segmented a bit. the *repository*
> > > should be viewed separately from the representation/wire
> > > transmisson protocol.
> > >
> > > xml is full of beauty, but it's comparatively inefficient as a storage
> > > media.
> > >
> > > fwiw. WinCE uses a DB for all of PIM-ish things. it was a source of much
> > > derision at the time of it's announcement because most folks pictured MSFT
> > > putting a copy of ACCESS on the device or something.
> > >
> > > but really, it's the right way to go, because both the size and the access
> > > time scales well as more stuff gets put in it.
> > >
> > > i *believe* that simply using gdbm as the runtime would get the data
> > > stored correctly *and* not require the reinvention of the wheel.
> > >
> > > so, then the next issue would be the 'wire protocol'. I would suggest
> > > using vCalendar because it permits PIM interoperability.
> > >
> > > For the things *not* supported in VCal, use XML.
> > >
> > > so, assuming that gdbm works out, then a wrapper that speaks VCal would be
> > > required, and it may already exist somewhere, likewise for XML.
> > >
> > > if not, then, that might be a good sourceforge spinoff 'cause it would be
> > > generally applicable beyond pgui.
> > >
> > > the other question about XML would be about choosing to be picky about
> > > wellformedness or *validity* ( ie checking against a DTD ). Validation is
> > > The Right Thing(tm) but it's way slow and way comsumptive.
> > >
> > > if one where to skip validation( validation in the XML DTD sort of sense
> > > ), then there are some lightweight xml parsers out there specifically for
> > > embedded apps.
> > >
> > > it would still be possible to 'validate' the data by making sure that the
> > > apps that wrote it 'always' did it right in the first place.
> > >
> > > just my 0.02
> > >
> > > johnu
> > >
> > >
> > > On Tue, 7 Aug 2001, Tasnim Ahmed wrote:
> > >
> > > > Hello:
> > > >
> > > > I got my Helio (a PDA) from a company designing a framework for it, but they
> > > > could not manage to fit it on 2MB ROM and 75 MHz MIPS processor, while
> > > > PicoGUI seems fine on same hardware.
> > > >
> > > > There we had a complete XML based framework while UI was also based on XML
> > > > and rendered by a java based engine which applied themes on it.... the
> > > > result, obviously performance hit.
> > > >
> > > > I just think if we consider picoGUI to be scalable we can just use binary
> > > > random access files using libc / dietlibc or whatever, and leave the big
> > > > desktops do the sync magic into anything in the world, if you know the
> > > > protocol, you can do it. however, standard files for basic PIM apps can be
> > > > kept standard and leave it documented for any new applications to "LINK"
> > > > (foreign key) to/from that data and keep the rest in their own file. Or we
> > > > can start working on a nifty file based db engine to handle requests from
> > > > applications while restricting to special casses when we know the data we
> > > > are storing is no more than 10000 records of a person of many corporate
> > > > contacts, 10 meetings a day and anniversaries of 10 friends every day of the
> > > > year. And if a guy has more memory he would obviously have a faster
> > > > processor to cover up slowing db engine while searching through.
> > > >
> > > > just my thoughts.
> > > >
> > > > -tasnim
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Pgui-devel mailing list
> > > > [EMAIL PROTECTED]
> > > > http://lists.sourceforge.net/lists/listinfo/pgui-devel
> > > >
> > >
> > > --
> > >
> > > John L. Utz III
> > > [EMAIL PROTECTED]
> > >
> > > Idiocy is the Impulse Function in the Convolution of Life
> > >
> > >
> > > _______________________________________________
> > > Pgui-devel mailing list
> > > [EMAIL PROTECTED]
> > > http://lists.sourceforge.net/lists/listinfo/pgui-devel
> >
> > --
> > Only you can prevent creeping featurism!
> >
>
> --
>
> John L. Utz III
> [EMAIL PROTECTED]
>
> Idiocy is the Impulse Function in the Convolution of Life
--
Only you can prevent creeping featurism!
_______________________________________________
Pgui-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/pgui-devel
