I have the following situation:
- the client use Palm
- the client wants a to make REMOTE synchronization with our server
- hum...
- i think that, if I can use pilot-link remotely then I can make this
job
What do you think about? How can I make this remote pilot-link
control?????
In my .cshrc:
setenv PILOTPORT net:any
Sitting at work, I can run any pilot-link command via ssh to my home
computer and then hit the net/wifi hotsync and it works fine. Setting
jpilot to use net:any also lets me run jpilot-sync to sync up my jpilot
stuff.
--
Doug Herr
doug*at*wombatz*dot*com
Another method I can think of are persistent filesystems (like roaming
profile or networked directory). I can't quite find a good link, but here's
something similar:
https://help.ubuntu.com/community/LiveCDPersistence (USB, not network)
Personally, I SSH to the computer where the cradle resides (home) and do
everything that's front-end (e.g. KCalendar) via X11.
Best wishes,
Roy
--
Roy S. Schestowitz
http://Schestowitz.com | GNU is Not UNIX | PGP-Key: 0x74572E8E
roy pts/8 Fri Jul 28 17:03 - 17:03 (00:00)
http://iuron.com - proposing a non-profit search engine
Can you figure out a way to ssh *from the Palm (over Wi-Fi, using pssh)*
to the server, invoke pilot-link, then switch to hotsync on the palm?
Whenever I switch away from pssh, the connection seems to break, which
screws up seeing the output of pilot-link, which I want to see.
>jpilot to use net:any also lets me run jpilot-sync to sync up my jpilot
>stuff.
pilot-link is not particularly secure (It wasn't designed to be a
sync-server for the entire Internet, so its authentication is pretty
much nil, and this is about the best it can do given the protocol
built into Palms isn't prepared to present passwords or certs or
something). If you manually start up pilot-link, it's possible
(but unlikely, given the time window of a few seconds) some other
person finds it running before you do and syncs against your data.
I think you're asking for trouble if you leave pilot-link waiting
for a connection all the time, unless you use a firewall to limit
what IPs the connection can come from.
Gordon L. Burditt
>>jpilot to use net:any also lets me run jpilot-sync to sync up my jpilot
>>stuff.
>
> pilot-link is not particularly secure (It wasn't designed to be a
> sync-server for the entire Internet, so its authentication is pretty much
> nil, and this is about the best it can do given the protocol built into
> Palms isn't prepared to present passwords or certs or something). If you
> manually start up pilot-link, it's possible (but unlikely, given the time
> window of a few seconds) some other person finds it running before you do
> and syncs against your data. I think you're asking for trouble if you
> leave pilot-link waiting for a connection all the time, unless you use a
> firewall to limit what IPs the connection can come from.
Yup, very good point. I do have a firewall so am safe from this, but
would not consider it without one (but I would not want to be online
without one either).
--
Doug Herr
doug*at*wombatz*dot*com
I think I did not explained the situation pretty well:
- my clients use windows
- they have a linux server
- they want to make the appointments update using a delphi (yes, a
delphi) interface.
So, what I was supposed to do:
1. create a interface in Delphi to show some options :ok, I have
already done
2. host A: client and his palm. host B: the database that needs to be
updated
3. the delphi interface must call the palm (dificult): there is a lot
of different implementations but no one make all the process of the
synchronization (one needs a PRC , other need to register, other one
you must pay, and so on)
4. So, the one solution I found is the delphi (A) send to server (B) a
request to pilot-link (I prefer do not use JAVA) and then this server
program (B), through something like a .DCOM access the palm (A), and
get the data (A<--->B).
Why am I not using the DCOM? First, you need to pay. Second, my client
WANTS a lot use Delphi. So a run-command pilot-link would be perfect.
Thanks a lot,
Gustavo Laufer
Doug Herr escreveu: