Re: Postal address in Contacts?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Jun 20, 2008 at 1:51 PM, Patrick Ohly <Patrick.Ohly@xxxxxx> wrote:
> On Fri, 2008-06-20 at 08:53 -0600, Mark wrote:
>> On Thu, Jun 19, 2008 at 12:40 PM, Patrick Ohly <Patrick.Ohly@xxxxxx> wrote:
>> >>  Powerful, painless import and export
>> >> (and sync) are our friends.
>> >
>> > And you have that today? As someone who has worked on sync technology
>> > for quite a while now I can tell you that getting it right is exactly
>> > the PITA that you complain about. It just gets worse the more programs
>> > you want to sync with.
>> >
>>
>> I put "and sync" in parentheses for a reason: import and export is
>> easier to use and more powerful than sync, and at the same time is
>> easier to implement.
>
> It's less powerful. The user is restricted to an "edit on one device",
> "export", "import on second device", "edit there" cycle. True syncing is
> more flexible, but indeed, more difficult to implement.
>

No, sync is limited to certain types of physical connections, certain
protocols, certain fields, certain devices, etc. Import and export can
be done not only with any type of physical connection, but in fact
completely without one via sneakernet. Given a certain set of fields,
sync usually only works with a specific subset of those, which can
vary by device and/or app. However, if you have an exported file with
*all* the fields, each separate device or app can take advantage of
every field of which it is capable, without further limiting other
devices/apps further down the line, which all also have access to the
original set of fields.

You are confusing "convenience" with "flexibility". Syncing can be a
whole lot more *convenient*, once you have it properly set up (which
can be a real bear), but it is in no way as flexible or powerful as
import/export.


>> >> Integrated=proprietary+closed+PITA.
>> >> Import+Export=complete freedom between many completely different apps,
>> >> not only apps that perform similar functions, but completely different
>> >> functions.
>> >>
>> >> And the vCard format is incredibly clunky and limited. Not the best
>> >> choice for the only supported format.
>> >
>> > So what is the alternative format that gives you this "complete freedom
>> > between many completely different apps ... [with] completely different
>> > functions"?
>>
>> Easy! Plain old CSV format. It allows for any number of fields of any
>> size and data type, and good implementation of import uses templates
>> to eliminate repetition of field matching after the first time. I've
>> been using CSV for transporting data between completely different apps
>> for many years, and my experience with the N800 is the first time I've
>> had any issues with import/export.
>
> Isn't CSV limited to a fixed number of columns? How do you deal with
> contacts which can have an unlimited number of addresses, phone numbers,
> etc.?
>

Maybe, but I haven't personally run into any limitations with CSV yet.
I have run into nothing *but* limitations with vCard.

> You might have had negative experiences with specific vCard
> implementations, but the format itself is more flexible than CSV.
>
> --
> Bye, Patrick Ohly
> --
> Patrick.Ohly@xxxxxx
> http://www.estamos.de/
>

Not from the standards that I've been reading. The vCard standard has
a very specific and very limited set of data fields. There is no limit
on the type, name, or anything else on CSV fields. CSV is *far* more
flexible than vCard.

The problem with vCard is similar to that of PalmOS. (And it's
probably no coincidence that they were contemporaries.) It started out
with a very specific purpose, and was outstanding at that. However,
when it had an identity crisis and tried to be something new and much
broader, and at the same time keep full compatibility with the old
version, it lost its way and lost the market to the newer competition
that didn't have the old baggage to haul along.

Sometimes standards should be allowed to die. Compatibility at the
expense of usability is not a good tradeoff.

Mark
_______________________________________________
maemo-users mailing list
maemo-users@xxxxxxxxx
https://lists.maemo.org/mailman/listinfo/maemo-users

[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Big List of Linux Books]    

  Powered by Linux