> I agree. The communicating part is Pyrite, right? I haven't used
> Pyrite, but it looks like you're able to have pretty good control over
> the syncing process. Hooray for reverse engineering. Using Pyrite,
> transferring the pages to the palm is just about as fast as possible,
> correct?
Pyrite is built on Python, and Python has some known memory issues
(which are also plaguing our current parser). Not to start a religious war,
but the original conduit(s) were written in awk and sed, and the transfer
script to push the records from cache to pdb-on-Palm were written in perl.
> Can you be oblivious to the "HotSync name"? i.e. if I just wanted to
> send the pdb to the palm in the cradle, not caring whose Palm was in the
> cradle, could it do it?
Sure. Not a problem.
> But our problem still stands.. On Windows and Mac, we don't have that
> control over HotSync. PDBs only go to the HotSync name they're intended
> for.
Or the 'special field' of 'All Users'. If you have only one user on
the box, you get it installed for that one user. Dirk can probably elaborate
more on this part, since he's working on this exact type of functionality
right now.
> What do you mean by instance of a page? Plucker manages multiple
> versions of a single page?
Not currently, but it has to, if we're going to support Forms which
don't "lock" on the Palm themselves to prohibit filling them out more than
once.
> Why can't the form result pdb just be installed right then and there?
> Or, at least, put into the queue to be installed. You have an "install"
> directory with Pyrite/pilot-link, correct?
Not specifically, but you can easily use the $HOME directives in
~/.pluckerrc to tell the pdb where to go (or the -f /path/to/file switch on
the parser).
> If all static content is prepared for installation before the sync and
> all we process during the sync is forms, it may not be too bad since we
> can gather the form response while installing the static content.
BZZT! Not a good idea. What if you have 40 forms filled out and 20
of the sites are down or busy. Do you want your Palm sitting in the cradle
for 30 minutes while gethostbyname() and friends time out looking up the
domain name, which could potentially be down?
We definately have to think about this sync order more carefully,
before we begin implementing something using it.
> Why you wouldn't want to use libssl?
No reason why we can't, but it's one more thing we have to require
the users recompile Python to support, one more dependancy which must be
ported to the other architectures, and one more hassle of maintaining
functionality and compatibility.
> To get to the second form you're going to have to post correct
> information to the first one. For a three-page form sequence, in the
> most ideal case there'd be no way around syncing at least 3 times.
You see my point.
> 1) get controls embedded in Plucker documents
> 2) next, be able to store their results and retrieve them on a sync
> 3) next, be able to parse a response and install it on the palm
> 4) next, be able to manage multiple form submittals/responses
> I'd feel a lot more comfortable planning everything else once we have a
> base like this to work with.
I fully agree. I'm just playing my normal role to make sure we don't
design an architecture which doesn't take these into (future)
consideration. We don't want to have to reinvent the solution because we
forgot to add a placeholder for something we're planning on supporting in
version 1.1 of the Forms Engine.
/d
