🚀 go-pugleaf

This was sent to me by Jeff Mitchel, the author of ShadowPlan. From 
reading this and many other things Jeff has written I can tell he really 
knows his way around the Palm OS and programming in general.
----------------

	For the record, Shadow only adds to the Note field if you ask it
to. What is listed is the Shadow Plan filename and a summary of the
parental hierarchy leading to the item (to make it uniquely 
identifiable). DateBk4 & 5
have a much higher use of the note field due to it living entirely
in those databases. Same with Agendus/AN. Not sure how many other apps
touch those fields.

	XML may not be appropriate, though it is most flexible; making
something XML-like but very pared down could be do-able.. building a full
XML parser would be bloaty and uncool on older units. (XML parsing at
16MHz can be savage. Been there, done that, made me unhappy :) (Remember
"XML" implies a lot) Also note that since Palm OS is international, using
XML with a number of encodings to support multiple languages gets clumsy
fast in the Notes field. But anyway.

	I think your goal needs to be clarified. One never chooses the
transport before the cargo.. choosing XML before narrowly defining the
objective is bad. Let us narrow down the exact goals, then chose an
appropriate transport mechanism. (Classic design fallacy number one :)  
One does not decide what language to use to build an app, until one
decides the app and what platform, and all that. But too commonly you see
someone start hacking away with no idea..

	Is the goal to make it easy for apps not to show a note attachment
icon when meta data is present? Or is it to allow interoperability? ( 
Very
different goals. One is simple, the other could be done via API or data
tagging or other methods..)

	Something to wonder about is where Palm OS 6 is taking it.. when
the format of the databases will change (or will it?) If the database
format changes, one must hope that Palm will define an extension 
mechanism
(for arbitrary extensions and extension ownership).. the existing
databases are badly designed, since obviously no expansion can be done
(and it is uncool to put extension data *after* the note, even though it
wont' break the built in applications to do so). It could be interesting
to build a key/value pair system after the note, but it is too easily 
lost by the built ins since they truncate like mad.

	So.. if your goal is to simply hide the note icon, then folks need
only agree on a termination character.. the note no longer exists after
some sequence of characters, say. Then agree on some way of defining a
header.. i.e.: One could make a terminator of ###Coog where ### is the
terminator and Coog is my Shadow creator-id. Then everything until a 
space or another terminator would be Shadow specific. Say.

	Easy.

	Or if the goal is interopability, then one must be more careful to
agree on a system easily parsed.

	But a goal needs be defined first :)

> 	Now, if there were an XML standard and all of this extra data were 
> tagged using XML, then it might be possible to write a hack that would 
> cause apps to ignore text within XML tags when deciding whether to 
> display the note icon. They could also hide all the XML data when the 
> user is adding their own notes rather than just hiding their own 
> proprietary data like DateBk5 does now.

	Hacks aren't supported in OS5, and a Hack doing so would likely
cause meta data loss. i.e.: If the Hack suppressed it on read, then any
update to the item would lose the meta data. If it was suppressed on
display, likely the same problem.. edit a field, the meta data hidden,
chances are it would be lost when the application reads the Field 
contents
back in.

	It is best for the apps to be aware instead.

> 	You could even use XML data to create outlines within the notes 
> fields of the Basic Four apps without even having to go to a separate app 
> like ShadowPlan. Not that outliners like ShadowPlan would be obsolete but 
> it would be handy to have a subset of it's functionality directly within 
> the note of a basic four item.

	Notes are 4k limited, and data access needs to be fast. Theres a
reason the system isn't just one big long text pad with all apps dipping
into it. Using your own database has a very good set of reasons ;) You
don't have ram to blow away keeping giant parse trees in memory, so you
need to format the data for speed of read :)

> 	The ideal situation would be if Palm jumps on the bandwagon and
> creates a special field just for this extra XML data. An interim step
> would be if they would just cause the Basic Four apps to not display
> XML data as standard note text and allow unlimited note field sizes.

	If Palm changes the format, they'll do it a lot better (I would
assume) than just adding an XML field; a generic extension mechanism is 
not
hard to make. i.e.: A field "number of fields" and a field to hold a 
table
identifying where the fields begin works (i.e.: a pdb), or a key/value
system or any number of methods. See RADIUS attributes for fun.. simple
and worked well for a decade or so now.

> Now, I'm not a programmer (yet) nor am I an expert in XML. So I
> wouldn't be able to really spearhead this endeavor but I sure would
> like to use the apps that could be developed using this approach. I am
> just writing this to get the ball bouncing around in peoples heads.

	1) Nail down agreeable objectives
	2) Decide how to fulfill those objectives
	3) Sanity check.. worth doing?
	4) Decide how to implement (2)

	Sorry for quick thoughts; I'm on the way out the door, but thought
I'd spew out a half baked response right away. Apologies for not being
clear or going into depth,

		jeff