🚀 go-pugleaf

Grant Robertson <BOGUS@BOGUS.INVALID> writes:

> 	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.

Why XML? One of the beauties of the Palm is that the data files are
very small. XML has a lot of nice features, but small data isn't one
of them.

All the advantages you want would accrue to any standard that was
endorsed and published by Palm, not just XML. Hopefully, they could
come up with something more lightweight than XML.

        <mike
-- 
Mike Meyer <mwm@mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

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	

In article <x7hecerrem.fsf@guru.mired.org>, mwm@mired.org says...
> Grant Robertson <BOGUS@BOGUS.INVALID> writes:
> 
> > 	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.
> 
> Why XML? One of the beauties of the Palm is that the data files are
> very small. XML has a lot of nice features, but small data isn't one
> of them.
> 
> All the advantages you want would accrue to any standard that was
> endorsed and published by Palm, not just XML. Hopefully, they could
> come up with something more lightweight than XML.

XML is the only thing I could think of. It wouldn't have to be a full XML 
implementation. Just something that uses plain text that could be agreed 
upon by all developers.

>	But that is just the beginning. Now applications could use each 
>other's data and add even more features.

Although not using XML, that is the way many applications work in
Psion Epoc PDAs.  You can embed objects in applications, and when
encountered, the appropriate application handles the display or
operation of the embedded object.  

Epoc Word can include Sketch objects, or Sheet and Graph objects,
or Record objects for voice output, or another Word document as
an object (and so on).  Epoc Jotter can contain the same four
objects, as can Epoc Data, and Epoc Agenda (the diary, PIM, todo
application). This seems to me to enormously increase the
versatility of the built in applications.

For example, you can do an invoice for printing in Epoc Word,
with your company letterhead from Sketch, a table of invoiced
items from Sheet, and a signature from Sketch.  Or a Data file of
your CDs with pictures of the covers, and short music files
associated with each record.  Or a Data file of say product
details with interactive Sheet objects to automatically calculate
quantity and retailer discounts for each type of item, or do do
currency conversions or whatever you like.  I think it is a great
idea, and extends what each individual application can do
enormously. Sometimes I would prefer that you could also embed
some of the "stateless' applications, like say the Calculator,
although this isn't as much of a need (because you can have
dozens of applications open simultaneously), and would make
converting files to a PC even trickier.

It does make it a bit hard defining file formats, because you end
up with a stream where various bits are identified automatically
by the appropriate application. It also makes it possible to
generate a file that can't be converted.  For example, if you
make a Data file with massive amounts of Sketches or photos, you
can make it as large as your Compact Flash.  It will still run,
because each Data record is brought into memory only when
accessed.  However if converting it on a PC to say MS Access, it
seems to act as if the entire database must fit in working
memory, so if your memory is smaller than the Compact Flash ...

-- 
Eric Lindsay          http://www.ericlindsay.com/guff
Airlie Beach Qld Australia - Great Barrier Reef entry
Psion & Epoc site     http://www.ericlindsay.com/epoc

In article <3e222879.25505886@news.bigpond.com>, spam2001@ericlindsay.com 
says...
> >	But that is just the beginning. Now applications could use each 
> >other's data and add even more features.
> 
> Although not using XML, that is the way many applications work in
> Psion Epoc PDAs.  You can embed objects in applications, and when
> encountered, the appropriate application handles the display or
> operation of the embedded object.  
> 
> Epoc Word can include Sketch objects, or Sheet and Graph objects,
> or Record objects for voice output, or another Word document as
> an object (and so on).  Epoc Jotter can contain the same four
> objects, as can Epoc Data, and Epoc Agenda (the diary, PIM, todo
> application). This seems to me to enormously increase the
> versatility of the built in applications.

I'm not really looking for embedded objects. Just a standardized way of 
storing extra data within the notes fields.