Subject: Re: [TS] Fidelity of Palm conversion
From: Jack Nutting (jnutting@baldwin.rat.se)
Date: Wed Apr 12 2000 - 05:10:49 EDT
> For example, suppose the desktop version allows notes marked up with
> HTML. How should the Palm version handle these? Ignore them? Show
> them to the user as plain text? Strip out the HTML codes? Should they
> not even be transfered to the Palm in the first place? Stripping the
> HTML codes seems like the most user-friendly option, but it leads to
> loss of markup if the text is changed on the Palm, then synced back to
> the desktop. I think that in this case it is clear that showing the
> raw HTML as text is the best approach, but this causes problems in
> synchronization:
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?
> TS-Desktop currently uses MIME types to indicate the type of data stored
> in an idea (e.g. "text/plain", "text/html"). TS-Palm uses integers from a
> list defined at compile-time. There is no number in this list for HTML,
> so HTML notes must be identified as the number for plain text. If the
> user changes the text on the palm and then syncs, the conduit will see a
> HTML note and a modified plaintext note, which it must try to resolve.
> The current behavior is to replace the HTML note on the desktop with the
> text note from the handheld. Thus, now the user will see the raw HTML
> on the desktop, whereas it used to be displayed properly.
>
> There are several ways to make this work correctly (i.e. not change the
> type):
> * Add an entry to the Palm version's list for HTML - this works in this
> case, but a more general solution is preferable
> * 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.
> * 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.
> so a text note on the Palm could match a text
> or HTML note on the desktop. The problem is that the user could have
> changed anything from a single character to the entire note, so there is
> no way to match them up (perhaps a heuristic could be employed, such as
> using an algorithm like that of 'diff' to determine the amount of text
> changed, or simply looking for HTML tags). One solution is to add
> locally unique IDs to each item in an idea.
> 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.
> 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".
-- Jack Nutting : jnutting@orcsoftware.com Orc Software : www.orcsoftware.com------------------------------------------------------------------------ Enter to WIN one of 10 NEW Kenmore Ranges! Only at sears.com http://click.egroups.com/1/2677/4/_/6321/_/955530790/ ------------------------------------------------------------------------
This archive was generated by hypermail 2b25 : Wed Aug 30 2000 - 22:01:01 EDT