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