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
