Re: [Evolution] Re: Syncing Evolution

["Paul M. Bucalo" <pmbuc pmbservices com>]

On Sun, 2005-02-06 at 18:05 +1100, Andrew Greig wrote:
> Hi all,
>
> I had a Palm iii with a serial cradle, getting it to work under Linux 
> with Evo 1.4.6 was easy.  Symlink /dev/ttS0 /dev/pilot , change the 
> permissions to 777 set up Gnome Pilot tp look for /dev/pilot and hit the 
> hot sync button.

If we drop devfs and udev, we can do that, but suffer the consequences
of having to "manualize" every device connection thereafter. Not really
the best answer for the masses and the progression of the O/S. I would
love to be able to make such nodes and symlinks to coincide with
devfs/udev, but it doesn't look like it will happen that way. I believe
that's where the 'rules' file comes in. But, the conduits also have to
be able to work with the system. 

> USB has been an extremely difficult proposition.  I think it is because 
> Linux does not take usb networking very seriously.  

I would think it's not a matter of "[not taking] seriously" as it is
about the difficulty in making it work. Hotplugging with USB has been a
slow-to-grow child in Linux. Then there is the need for cooperation
between O/S and device interface applets/applications. 'gplitod' is an
old program. A revamp is definitely needed. Isn't it still gtk1 while
Evolution has been gtk2 for a while?

> The greatest joy I 
> had with usb networking was with Mandrake 8.2, still one of their best 
> ever in my view.

I can't recall if Mdk 8.x used devfs. It's been so long since I ran that
version of Mdk. :0) If you can set up symlinks in /dev and they stay, I
would think not. Or maybe it's the lack of hotplugging?

> ...check out your 
> /etc/dynamic/scripts/visor.script, here is the Mdk10 one,

Doesn't exist in FC3, at least not in that directory...

> #!/bin/sh
> #---------------------------------------------------------------
> # Project         : Mandrake Linux
> # Module          : dynamic
> # File            : visor.script
> # Version         : $Id: visor.script,v 1.3 2001/09/17 15:25:38 flepied 
> Exp $
> # Author          : Frederic Lepied
> # Created On      : Thu Sep 13 01:09:08 2001
> # License         : GPL
> # Purpose         : script run when a new visor or palm is plugged.
> #---------------------------------------------------------------
>
> . /etc/dynamic/scripts/functions.script
>
> check_activated $0
>
> if [ $1 = add ]; then
>     ln -sf $2 /dev/pilot
> else
>     rm -f /dev/pilot
> fi
>
> call_hooks $1 visor $2 ""
>
> # visor.script ends here

I was just replying back to a list member that it may be that if I can
get gpilotd to startup (like from a script in /Desktop/Autostart, but as
a daemon, not with screen output), the problem would be solved. All I
need is for the physical presence of gpilotd in memory to make a sync
work on the first try. It then continues to run in memory until the next
reboot, shutdown, or is manually killed. Anyone good at scripting want
to draft up such a script, with some error trapping to make sure that it
won't load again if already in memory? :0)

> I spent a bit of time in the /dev directory watching what happened when 
> I hit the sync button on a usb Sharp Zaurus.
>  A node would be formed /dev/usb0 and then nothing much happened and it 
> dropped out again.

And once a good sync is finished, a 'successful' node and corresponding
symlink disappears. It's getting the node and symlink created in time
for the syncing process that is the problem here.

> Now, I am not a scripter, let alone a programmer, but maybe a permanent 
> node for usb0 needs to be made, so that the gnome-pilotd has time to 
> access it.  It should not have to be dependent on "tricky timing".  
> Interestingly my usb printer works a breeze, my usbkey gets automounted 
> and works great, my digital camera usb cable works perfectly so why is 
> so hard for a Palm. 

As I have seen it, the printer is made a permanent connection because it
is in constant communication with the system while it is on. Turn it off
and I believe the node and symlink will disappear from your system. It
should reappear the next time your system senses the printer is on. Palm
syncing is dependent on dynamic conduit(s). Its the conduit applet that
is failing to be there for the device in time for a sync.

USB storage devices are treated differently...they are mounted, like
drive. The connection and disconnection notifies devfs or udev and a
mount is made (if the device is recognized by your system). A Palm
device sync is dynamic and communicates only for as long as the sync is
in progress. That's where gpilotd comes in, or whatever is being used in
jpilot, etc. Even jpilot will fail to sync on my system if I don't get
the "timing" right on pushing buttons within the program and the
device. 

Also, neither jpilot or Evo would sync with my Handspring without the
addition of specs to recognize and setup a node/symlink
in /etc/udev/rules.d/50-udev.rules. Why these specs are not already
there from the onset is a mystery to me. 

> I have other problems with duplicates on my Palm 
> because I sync with the Windows side of the machine, and with 
> evolution.  I have been thinking about this and I have concluded that 
> there may be 2 data sets there, one for the Windows user number and one 
> for my normal user number eg 501. 

There are. You have two identities setup in your Palm.

> I will clean up my Palm and try a 
> fresh sync with Linux first.  If that works OK there is no need for a 
> Windows sync at all.  I am hoping that I may be able to sync my data 
> with OpenOffice.org, possibilities for form letters, there.

Each application you add to the syncing process has the potential to
create a new identity or require a separate set of data. If you want to
avoid that, I suggest that you do not create conduits that overlap.

> Enough rambling, would love to see a solution

The fact that many do not have the problems we speak of here implies to
me that they have something in their systems that we do not. Once that's
found, it can be replicated and the problem is solved. Half the battle
in getting answers within Linux is finding someone who already has what
you need so you don't have to reinvent the wheel yourself. ;0)

Paul