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
_______________________________________________
Pgui-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/pgui-devel
