Re: [TS] Fidelity of Palm conversion


Subject: Re: [TS] Fidelity of Palm conversion
From: Ben Darnell (bgdarnel@unity.ncsu.edu)
Date: Wed Apr 12 2000 - 09:16:17 EDT


On Wed, Apr 12, 2000 at 11:10:49AM +0200, Jack Nutting wrote:
> Speaking of HTML markup, one idea I'd like to promote as an
> alternative is the one someone mentioned before, of using a sort of
> plain-text based markup, so that if the text is read with a simple
> text reader it just looks like text, but for an enabled text reader
> the hints from spacing and punctuation will provide some formatting.
> Does anyone remember the URL for this?

There are several variations on this idea; one of them is Zope's
StructuredText:
http://www.zope.org/Members/millejoh/structuredText
I had almost forgotten this; it'll definitely be included.

> > * Change the type field on the Palm to a string, so that the full mime
> > type can be specified - I like this, although it does use a lot of
> > space. Maybe a numeric list could be used for popular types, with
> > a textual field for unknowns.
>
> I like this alternative, I don't think the space difference should be that
> much. Say you've got 10,000 typed data chunks (i.e. a HUGE database), and
> the average mime type string is 10 chars, then you're talking about an extra
> 100k of space. This is most likely dwarfed by the overall size of the data
> itself.

Point noted.

>
> > * Somehow make the conduit smart enough to recognize that the two
> > notes were once the same - This is hard to do right. The conduit
> > knows that the Palm doesn't do HTML,
> ^^^^^^^^^^^^^^^^^^^^^^^^
>
> Question: Why not let the Palm version "do HTML"? I don't mean full
> HTML, but some reasonable (and easily parsable) subset. Use the same
> subset in the desktop markup so there will be no confusion. An
> initial implementation (for simplicity's sake) could even have the
> Palm version ignoring all tags, but leaving them intact.

That would be great, but very difficult to do. The most likely way for
this to happen is with a plugin which processes the data and passes it off
to Plucker or a similar program.

> > Another example:
> > Suppose Natrificial finally gets around to releasing their Palm version
> > of TheBrain and people start using it. A user of this program beams
> > one or more thoughts to you, which ThoughtStream accepts. Suppose
> > TB-Palm supports some construct which TS-Palm does not, but TS-Desktop
> > does. Should TS-Palm discard the data it doesn't understand, or should
> > it retain it for the use of TS-Desktop?
>
> I think the data should be retained in a case like this, based on the
> principle that it's better to have the "entrance" to your product be
> as wide-open as possible, the notion that if data from foreign
> sources can easily move into your system, people will be more likely
> to use your system. If that data was thrown away, a potential user
> might be frustrated at not being able to use data beamed to him from
> a TB-Palm user, and may therefore end up using TB instead of TS.
>

I agree.

> > In other words, should we just accept the fact that data will be reduced
> > to the lowest common denominator of the applications through which it
> > has passed, or should we try to preserve the data as faithfully as
> > possible? The lowest-common-denomiator approach does cause
> > complications for synchronization, but is the space/complexity cost of
> > preservation worth it?
>
> One option is to make this be a user-definable preference. A checkbox that
> says "Ignore desktop-only datatypes".

It's not really "desktop-only", because the Palm doesn't know what the
desktop supports. But a "Strip unknown datatypes" option would be a
good thing.

-Ben

-- 
Ben Darnell              bgdarnel@unity.ncsu.edu
http://thoughtstream.org
Finger bgdarnel@debian.org for PGP/GPG key 1024D/1F06E509

------------------------------------------------------------------------ Enter to WIN one of 10 NEW Kenmore Ranges! Only at sears.com http://click.egroups.com/1/2677/4/_/6321/_/955545383/ ------------------------------------------------------------------------



This archive was generated by hypermail 2b25 : Wed Aug 30 2000 - 22:01:01 EDT