Salut tout le monde,
j'ai une nouvelle fois besoin de vous !!
J'ai aujourd'hui 3 macs reliés en réseau via Airport.
J'utilise iCal pour la gestion de mes calendriers et mon carnet
d'adresses.
Je souhaiterais que mes 2 employés aient accès à mon calendrier et mon
carnet d'adresses, mais pas via Internet, puisque leurs postes n'a pas
d'accès (la borne ne sert qu'au réseau).
Y a-t-il un moyen plus ergonomique et pratique que l'exportation, car
avec l'exportation, ils ne peuvent pas mettre à jour mon agenda.
Merci de votre aide (c évidemment urgent, alors je compte sur vous !!)
It's iCal's deficiency, it only subscribes read-only or publishes write-only. You could do what Dmitry suggested, which is subscribe and publish two calendars. But the secretary could not "change" an Executive's event in iCal if the event was in his calendar.
Mais possible avec .mac d'où la certitude d'un bridage!
La, je veux bien de la pédagogie : je ne comprends pas comment tu déduis que ical est bridé... Car grosso-modo, il est proposer d'utiliser 2 calendriers pour eviter les conflits.
Pour le reste merci pour ta pédanterie: impression de néophyte (+ de 25 ans à partir du 1er Apple II arrivé en France), ignorance (pas plus que tout le monde, mais plus que toi évidement)
Tu sous-entends que tu es developpeur depuis 25 ans ou utilisateurs depuis 25 ? Dans le deuxieme cas, c'est pas parce qu'on sait conduire qu'on apprends la mécanique...
Georges Desort <spam@jean.nux.info> wrote:
It's iCal's deficiency, it only subscribes read-only or publishes
write-only. You could do what Dmitry suggested, which is subscribe and
publish two calendars. But the secretary could not "change" an
Executive's event in iCal if the event was in his calendar.
Mais possible avec .mac d'où la certitude d'un bridage!
La, je veux bien de la pédagogie : je ne comprends pas comment tu déduis
que ical est bridé... Car grosso-modo, il est proposer d'utiliser 2
calendriers pour eviter les conflits.
Pour le reste merci pour ta pédanterie: impression de néophyte (+ de 25
ans à partir du 1er Apple II arrivé en France), ignorance (pas plus que
tout le monde, mais plus que toi évidement)
Tu sous-entends que tu es developpeur depuis 25 ans ou utilisateurs
depuis 25 ? Dans le deuxieme cas, c'est pas parce qu'on sait conduire
qu'on apprends la mécanique...
It's iCal's deficiency, it only subscribes read-only or publishes write-only. You could do what Dmitry suggested, which is subscribe and publish two calendars. But the secretary could not "change" an Executive's event in iCal if the event was in his calendar.
Mais possible avec .mac d'où la certitude d'un bridage!
La, je veux bien de la pédagogie : je ne comprends pas comment tu déduis que ical est bridé... Car grosso-modo, il est proposer d'utiliser 2 calendriers pour eviter les conflits.
Pour le reste merci pour ta pédanterie: impression de néophyte (+ de 25 ans à partir du 1er Apple II arrivé en France), ignorance (pas plus que tout le monde, mais plus que toi évidement)
Tu sous-entends que tu es developpeur depuis 25 ans ou utilisateurs depuis 25 ? Dans le deuxieme cas, c'est pas parce qu'on sait conduire qu'on apprends la mécanique...
Hubert Figuiere
It's iCal's deficiency, it only subscribes read-only or publishes write-only. You could do what Dmitry suggested, which is subscribe and publish two calendars. But the secretary could not "change" an Executive's event in iCal if the event was in his calendar.
Mais possible avec .mac d'où la certitude d'un bridage!
Oui, mais non. Il s'agit bien d'une méconnaissance du fonctionnement de l'ensemble. Le principe de iSync, et c'est ce que fait .Mac derrière, c'est de travailler enregistrement pas enregistrement afin de permettre la modification en simultané des calendriers ou carnet d'addresse depuis pluis copies et de répercuter les modifications à l'ensemble de ces copies. C'est ce que fait iSync avec les téléphones, les PDA et .Mac. Du reste, là dessus, .Mac est bien un cas à part, cf infra.
Ca veut dire que si tu modifie un evénement dans ton PDA et un autre dans ton Mac et que tu resynchronise, les modification vont être transportées dans l'un et l'autre, de manière transparente. Si tu modifie le même évenement, il va s'en appercevoir, te le dire, et te montrer les différence pour que tu puisse choisir.
Maintenant, .Mac est un cas à part dans ce schéma vu qu'il va gérer les modification de manière bi-directionnelle vers plusieurs sources, à savoir les différent macs. Il reprend le schéma ci-dessus, qu'une simple publication WebDAV ne permet pas d'accomplir.
Quand à la publication en WebDAV, peut-être pourra-tu répondre aux question suivante:
1/ comment tu sais ce que X à modifié
2/ si X modifie le calendrier sur sa machine et publie. Y a modifié le calendrier sur sa machine et veut publier. 2 solutions: soit il met à jour avant et ses modifs sont écrasées. Soit il publie et dans ce cas il écrase les modifs de X. Si tu pense "il yaka récupérer les modifs", il suffit de repartir sur la question 1/
Pour le reste merci pour ta pédanterie: impression de néophyte (+ de 25 ans à partir du 1er Apple II arrivé en France), ignorance (pas plus que tout le monde, mais plus que toi évidement)
MDR. Ultra MDR.
"iCal/WebDAV" et "Exchange/Outlook" doivent à terme fonctionner de la même manière, tout au moins pour la fonction Calendrier.
Parlons en à Microsoft.
Hub
PS: tu goret-quote. Merci de lire <http://www.usenet-fr.net/fur/usenet/repondre-sur-usenet.html>
It's iCal's deficiency, it only subscribes read-only or publishes
write-only. You could do what Dmitry suggested, which is subscribe and
publish two calendars. But the secretary could not "change" an
Executive's event in iCal if the event was in his calendar.
Mais possible avec .mac d'où la certitude d'un bridage!
Oui, mais non. Il s'agit bien d'une méconnaissance du fonctionnement
de l'ensemble.
Le principe de iSync, et c'est ce que fait .Mac derrière, c'est de
travailler enregistrement pas enregistrement afin de permettre la
modification en simultané des calendriers ou carnet d'addresse depuis
pluis copies et de répercuter les modifications à l'ensemble de ces
copies. C'est ce que fait iSync avec les téléphones, les PDA et .Mac.
Du reste, là dessus, .Mac est bien un cas à part, cf infra.
Ca veut dire que si tu modifie un evénement dans ton PDA et un autre
dans ton Mac et que tu resynchronise, les modification vont être
transportées dans l'un et l'autre, de manière transparente. Si tu
modifie le même évenement, il va s'en appercevoir, te le dire, et te
montrer les différence pour que tu puisse choisir.
Maintenant, .Mac est un cas à part dans ce schéma vu qu'il va gérer
les modification de manière bi-directionnelle vers plusieurs sources,
à savoir les différent macs. Il reprend le schéma ci-dessus, qu'une
simple publication WebDAV ne permet pas d'accomplir.
Quand à la publication en WebDAV, peut-être pourra-tu répondre aux
question suivante:
1/ comment tu sais ce que X à modifié
2/ si X modifie le calendrier sur sa machine et publie. Y a modifié le
calendrier sur sa machine et veut publier. 2 solutions: soit il met à
jour avant et ses modifs sont écrasées. Soit il publie et dans ce cas
il écrase les modifs de X. Si tu pense "il yaka récupérer les modifs",
il suffit de repartir sur la question 1/
Pour le reste merci pour ta pédanterie: impression de néophyte (+ de 25
ans à partir du 1er Apple II arrivé en France), ignorance (pas plus que
tout le monde, mais plus que toi évidement)
MDR. Ultra MDR.
"iCal/WebDAV" et "Exchange/Outlook" doivent à terme fonctionner de la
même manière, tout au moins pour la fonction Calendrier.
Parlons en à Microsoft.
Hub
PS: tu goret-quote. Merci de lire
<http://www.usenet-fr.net/fur/usenet/repondre-sur-usenet.html>
It's iCal's deficiency, it only subscribes read-only or publishes write-only. You could do what Dmitry suggested, which is subscribe and publish two calendars. But the secretary could not "change" an Executive's event in iCal if the event was in his calendar.
Mais possible avec .mac d'où la certitude d'un bridage!
Oui, mais non. Il s'agit bien d'une méconnaissance du fonctionnement de l'ensemble. Le principe de iSync, et c'est ce que fait .Mac derrière, c'est de travailler enregistrement pas enregistrement afin de permettre la modification en simultané des calendriers ou carnet d'addresse depuis pluis copies et de répercuter les modifications à l'ensemble de ces copies. C'est ce que fait iSync avec les téléphones, les PDA et .Mac. Du reste, là dessus, .Mac est bien un cas à part, cf infra.
Ca veut dire que si tu modifie un evénement dans ton PDA et un autre dans ton Mac et que tu resynchronise, les modification vont être transportées dans l'un et l'autre, de manière transparente. Si tu modifie le même évenement, il va s'en appercevoir, te le dire, et te montrer les différence pour que tu puisse choisir.
Maintenant, .Mac est un cas à part dans ce schéma vu qu'il va gérer les modification de manière bi-directionnelle vers plusieurs sources, à savoir les différent macs. Il reprend le schéma ci-dessus, qu'une simple publication WebDAV ne permet pas d'accomplir.
Quand à la publication en WebDAV, peut-être pourra-tu répondre aux question suivante:
1/ comment tu sais ce que X à modifié
2/ si X modifie le calendrier sur sa machine et publie. Y a modifié le calendrier sur sa machine et veut publier. 2 solutions: soit il met à jour avant et ses modifs sont écrasées. Soit il publie et dans ce cas il écrase les modifs de X. Si tu pense "il yaka récupérer les modifs", il suffit de repartir sur la question 1/
Pour le reste merci pour ta pédanterie: impression de néophyte (+ de 25 ans à partir du 1er Apple II arrivé en France), ignorance (pas plus que tout le monde, mais plus que toi évidement)
MDR. Ultra MDR.
"iCal/WebDAV" et "Exchange/Outlook" doivent à terme fonctionner de la même manière, tout au moins pour la fonction Calendrier.
Parlons en à Microsoft.
Hub
PS: tu goret-quote. Merci de lire <http://www.usenet-fr.net/fur/usenet/repondre-sur-usenet.html>
spam
Julien Jalon wrote:
C'est pourquoi un simple serveur WebDAV suffit : PUT/GET et hop, on a du publish/subcribe).
Merci pour votre réponse, et celles d' Hubert Figuiére et Jérôme Lebel.
(Utilisateur depuis 25 ans je n'ai aucune prétention de développeur)
En fait sur mon serveur courriel.to (CGPro), en se connectant par l'interface Web, plusieurs utilisateurs peuvent partager un même calendrier qui se mets à jour automatiquement.
Ce calendrier est modifié non pas directement, mais par l'intermédiaire de création de "tâches" qui s'inscrivent dans le calendrier partagé.
Avec iCal je ne peux publier les tâches, j'ai l'erreur "impossible de publier le calendrier.Le serveur est indisponible et a renvoyé une erreur (500)"
Je pose peut être mal le problème ? Je suis peut être brouillon ? (à part ça Panther c'est génial)
-- Georges ( est valide pour les "humains" Visiter le serveur de messagerie Courriel.To Login et mot de passe: demo
C'est
pourquoi un simple serveur WebDAV suffit : PUT/GET et hop, on a du
publish/subcribe).
Merci pour votre réponse, et celles d' Hubert Figuiére et Jérôme Lebel.
(Utilisateur depuis 25 ans je n'ai aucune prétention de développeur)
En fait sur mon serveur courriel.to (CGPro), en se connectant par
l'interface Web, plusieurs utilisateurs peuvent partager un même
calendrier qui se mets à jour automatiquement.
Ce calendrier est modifié non pas directement, mais par l'intermédiaire
de création de "tâches" qui s'inscrivent dans le calendrier partagé.
Avec iCal je ne peux publier les tâches, j'ai l'erreur "impossible de
publier le calendrier.Le serveur est indisponible et a renvoyé une
erreur (500)"
Je pose peut être mal le problème ? Je suis peut être brouillon ?
(à part ça Panther c'est génial)
--
Georges
(spam@jean.nux.info est valide pour les "humains"
Visiter le serveur de messagerie Courriel.To
Login et mot de passe: demo
C'est pourquoi un simple serveur WebDAV suffit : PUT/GET et hop, on a du publish/subcribe).
Merci pour votre réponse, et celles d' Hubert Figuiére et Jérôme Lebel.
(Utilisateur depuis 25 ans je n'ai aucune prétention de développeur)
En fait sur mon serveur courriel.to (CGPro), en se connectant par l'interface Web, plusieurs utilisateurs peuvent partager un même calendrier qui se mets à jour automatiquement.
Ce calendrier est modifié non pas directement, mais par l'intermédiaire de création de "tâches" qui s'inscrivent dans le calendrier partagé.
Avec iCal je ne peux publier les tâches, j'ai l'erreur "impossible de publier le calendrier.Le serveur est indisponible et a renvoyé une erreur (500)"
Je pose peut être mal le problème ? Je suis peut être brouillon ? (à part ça Panther c'est génial)
-- Georges ( est valide pour les "humains" Visiter le serveur de messagerie Courriel.To Login et mot de passe: demo
Julien Jalon
Georges Desort wrote:
Ce calendrier est modifié non pas directement, mais par l'intermédiaire de création de "tâches" qui s'inscrivent dans le calendrier partagé.
C'est bien ça qui m'étonne... iCal n'a pas la notion de calendrier partagé (qui est différente donc du simple publish/subscribe).
Avec iCal je ne peux publier les tâches, j'ai l'erreur "impossible de publier le calendrier.Le serveur est indisponible et a renvoyé une erreur (500)"
Là, c'est pas bon pour le serveur. Il est possible que ce ne soit pas un serveur WebDAV (ou pas un "bon" serveur WebDAV). Qu'utilisez-vous comme "serveur WebDAV" ?
-- Julien Jalon <http://www.julien-jalon.org/>
Georges Desort <spam@jean.nux.info> wrote:
Ce calendrier est modifié non pas directement, mais par l'intermédiaire
de création de "tâches" qui s'inscrivent dans le calendrier partagé.
C'est bien ça qui m'étonne... iCal n'a pas la notion de calendrier
partagé (qui est différente donc du simple publish/subscribe).
Avec iCal je ne peux publier les tâches, j'ai l'erreur "impossible de
publier le calendrier.Le serveur est indisponible et a renvoyé une
erreur (500)"
Là, c'est pas bon pour le serveur. Il est possible que ce ne soit pas un
serveur WebDAV (ou pas un "bon" serveur WebDAV). Qu'utilisez-vous comme
"serveur WebDAV" ?
Ce calendrier est modifié non pas directement, mais par l'intermédiaire de création de "tâches" qui s'inscrivent dans le calendrier partagé.
C'est bien ça qui m'étonne... iCal n'a pas la notion de calendrier partagé (qui est différente donc du simple publish/subscribe).
Avec iCal je ne peux publier les tâches, j'ai l'erreur "impossible de publier le calendrier.Le serveur est indisponible et a renvoyé une erreur (500)"
Là, c'est pas bon pour le serveur. Il est possible que ce ne soit pas un serveur WebDAV (ou pas un "bon" serveur WebDAV). Qu'utilisez-vous comme "serveur WebDAV" ?
-- Julien Jalon <http://www.julien-jalon.org/>
spam
Julien Jalon wrote:
C'est bien ça qui m'étonne... iCal n'a pas la notion de calendrier partagé (qui est différente donc du simple publish/subscribe).
Merci, voilà la réponse, j'espère donc qu'Apple intégrera cette notion.
Mes excuses si j'ai été un peu long... -- Georges ( est valide pour les "humains" Visiter le serveur de messagerie Courriel.To Login et mot de passe: demo
C'est bien ça qui m'étonne... iCal n'a pas la notion de calendrier
partagé (qui est différente donc du simple publish/subscribe).
Merci, voilà la réponse, j'espère donc qu'Apple intégrera cette notion.
Mes excuses si j'ai été un peu long...
--
Georges
(spam@jean.nux.info est valide pour les "humains"
Visiter le serveur de messagerie Courriel.To
Login et mot de passe: demo
C'est bien ça qui m'étonne... iCal n'a pas la notion de calendrier partagé (qui est différente donc du simple publish/subscribe).
Merci, voilà la réponse, j'espère donc qu'Apple intégrera cette notion.
Mes excuses si j'ai été un peu long... -- Georges ( est valide pour les "humains" Visiter le serveur de messagerie Courriel.To Login et mot de passe: demo
jeromelebel
Patrick C wrote:
On peut beamer facilement d'un palm à l'autre: ensuite pour un synchro complète se serait lourd et sans intérêt.
De quoi tu parles ? On parle de synchro...
Je veux faire comprendre que lorsqu'on parle de synchro entre un mac et un ou plusieurs PDA, il y a un serveur : le mac. Donc si on veut syncroniser 2 macs ou plus, le systeme le plus est le meme : un serveur. Et c'est .mac.
Evidement, c'est faisable de syncroniser plus de 2 ordinateurs sans qu'il y ai un serveur, mais c'est vraiment pas le plus simple !
Donc si tu parles de passer de pousser l'information, on sort du sujet et surtout de ma comparaison.
Patrick C <cochardp@alussinan.org> wrote:
On peut beamer facilement d'un palm à l'autre: ensuite pour un synchro
complète se serait lourd et sans intérêt.
De quoi tu parles ? On parle de synchro...
Je veux faire comprendre que lorsqu'on parle de synchro entre un mac et
un ou plusieurs PDA, il y a un serveur : le mac. Donc si on veut
syncroniser 2 macs ou plus, le systeme le plus est le meme : un serveur.
Et c'est .mac.
Evidement, c'est faisable de syncroniser plus de 2 ordinateurs sans
qu'il y ai un serveur, mais c'est vraiment pas le plus simple !
Donc si tu parles de passer de pousser l'information, on sort du sujet
et surtout de ma comparaison.
On peut beamer facilement d'un palm à l'autre: ensuite pour un synchro complète se serait lourd et sans intérêt.
De quoi tu parles ? On parle de synchro...
Je veux faire comprendre que lorsqu'on parle de synchro entre un mac et un ou plusieurs PDA, il y a un serveur : le mac. Donc si on veut syncroniser 2 macs ou plus, le systeme le plus est le meme : un serveur. Et c'est .mac.
Evidement, c'est faisable de syncroniser plus de 2 ordinateurs sans qu'il y ai un serveur, mais c'est vraiment pas le plus simple !
Donc si tu parles de passer de pousser l'information, on sort du sujet et surtout de ma comparaison.
Julien Jalon
Jérôme Lebel wrote:
Evidement, c'est faisable de syncroniser plus de 2 ordinateurs sans qu'il y ai un serveur, mais c'est vraiment pas le plus simple !
Donc si tu parles de passer de pousser l'information, on sort du sujet et surtout de ma comparaison.
D'accord, je te l'accorde, ce n'est pas un bit, mais un octet complet.
-- Julien Jalon <http://www.julien-jalon.org/>
Jérôme Lebel <jeromelebel@mac.com> wrote:
Evidement, c'est faisable de syncroniser plus de 2 ordinateurs sans
qu'il y ai un serveur, mais c'est vraiment pas le plus simple !
Donc si tu parles de passer de pousser l'information, on sort du sujet
et surtout de ma comparaison.
D'accord, je te l'accorde, ce n'est pas un bit, mais un octet complet.
Evidement, c'est faisable de syncroniser plus de 2 ordinateurs sans qu'il y ai un serveur, mais c'est vraiment pas le plus simple !
Donc si tu parles de passer de pousser l'information, on sort du sujet et surtout de ma comparaison.
D'accord, je te l'accorde, ce n'est pas un bit, mais un octet complet.
-- Julien Jalon <http://www.julien-jalon.org/>
Rocou
Julien Jalon wrote:
Rocou wrote:
On peut publier un calendrier sur .mac comme on peut le faire sur un serveur WebDav ou sur un site du type icalx.com Mais on peut *aussi* synchroniser plusieurs ICal sur plusieurs machines différentes. Synchroniser signifie mettre à jour les changements le s plus récents sur tous les ICal concernés. Les modifs peuvent se faire à partir de n'importe quel ICal et se retrouver sur tous les autres. Ceci est impossible à faire sans .mac Sauf solution non officielle que j'aimerais connaitre plutôt que de subir les sarcasmes stupides que tu as pu observer :-(
Bon, je vais peut-être dire des conneries mais essayons de simplifier : En gros, la synchronisation entre A et B de données posent beaucoup d e problèmes. De nombreux conflits sont possibles, et il est compliqué de détermi ner proprement qui a raison entre A et B. Ce truc qui est sur A et pas sur B doit-il être effacé sur les deux ou ajouté à B ? Ce truc diffé rent entre A et B... lequel est la bonne version ? Et encore, ce n'est qu'entre A et B... imagine entre A, B, C, D et E... et le pire, c'est que ces zozios ne se synchronisent pas en même temps et parfois pas directement et o n pourrait imaginer que A se synchronise parfois avec B mais aussi avec E . Et puis, il se peut que quelques temps plus tard, il y ait un F qui viennent jouer avec les autres. En gros, tu dois gérer de l'informati on délocalisée, et ce n'est pas simple.
Pour avoir une synchro simple (à l'utilisation et à la configuratio n) et "sûre" (et la moins chère possible) pour l'utilisateur, il faut faire des choix techniques. Déjà, on évite tous les cycles possibles. S i tu regardes la structure, .Mac est le point central où se connectent tou s les Macs, les téléphones ne se connectent qu'à un Mac donné. Ai nsi, on est sûr que .Mac contient la "vérité" centrale des données. Le point de référence, quoi. Si tu n'as pas .Mac, c'est l'ordinateur qui fait o ffice de point central.
Pour finir, pour pouvoir synchroniser A avec B, il faut un client sur A et un serveur sur B. Les téléphones ont leur "serveur". Avec iSync, tu as le client et tu n'as pas besoin de serveur. .Mac lui a le serveur. Si tu veux passer outre .Mac, il te faudra une solution équivalente, et ne t'étonne pas si tu dois la payer (un presqu'équivalent : un serveur Exchange).
Si tu veux faire de la synchro de machine à machine, il faudra sûre ment faire aussi des choix limitants et ça risque d'être un peu plus compliqué à mettre en place (voir rsync alors que ce n'est que de l a synchro de fichiers). Tout ça ne semble pas être le propos d'iSync.
Voilà, il y a des propos ironiques, en effet, mais c'est qu'on voit souvent ce discours du "yaka" sans se rendre compte que, non, il n'y a pas toujours "ka". Le problème, c'est que ce n'est pas toujours facil e d'expliquer pourquoi "ilnyapaka".
Merci. Il n'en reste pas moins que désigner un poste comme serveur devrait rester possible. Il est dommage qu'Apple n'ait pas intégré une telle fonctionalité (ou facilité sa mise en place). A moins que la version "server" de Panther le fasse. Car il n'y a pas qu'Ical qui soit concerné mais aussi le carnet d'adresse, mail, safari, IChat, etc. Je pense en outre que ceux qui ne travaillent pas en réseau (sous Mac) ne peuvent pas appréhender l'intérêt d'une telle synchro...
Cela dit, je pense tout de même que synchroniser deux postes devrait faire partie des compétences d'iSync.
Julien Jalon wrote:
Rocou <de.kat@free.fr> wrote:
On peut publier un calendrier sur .mac comme on peut le faire sur un
serveur WebDav ou sur un site du type icalx.com
Mais on peut *aussi* synchroniser plusieurs ICal sur plusieurs machines
différentes. Synchroniser signifie mettre à jour les changements le s
plus récents sur tous les ICal concernés.
Les modifs peuvent se faire à partir de n'importe quel ICal et se
retrouver sur tous les autres.
Ceci est impossible à faire sans .mac
Sauf solution non officielle que j'aimerais connaitre plutôt que de
subir les sarcasmes stupides que tu as pu observer :-(
Bon, je vais peut-être dire des conneries mais essayons de simplifier :
En gros, la synchronisation entre A et B de données posent beaucoup d e
problèmes.
De nombreux conflits sont possibles, et il est compliqué de détermi ner
proprement qui a raison entre A et B. Ce truc qui est sur A et pas sur B
doit-il être effacé sur les deux ou ajouté à B ? Ce truc diffé rent entre
A et B... lequel est la bonne version ? Et encore, ce n'est qu'entre A
et B... imagine entre A, B, C, D et E... et le pire, c'est que ces
zozios
ne se synchronisent pas en même temps et parfois pas directement et o n
pourrait imaginer que A se synchronise parfois avec B mais aussi avec E .
Et puis, il se peut que quelques temps plus tard, il y ait un F qui
viennent jouer avec les autres. En gros, tu dois gérer de l'informati on
délocalisée, et ce n'est pas simple.
Pour avoir une synchro simple (à l'utilisation et à la configuratio n)
et "sûre" (et la moins chère possible) pour l'utilisateur, il faut faire
des choix techniques. Déjà, on évite tous les cycles possibles. S i tu
regardes la structure, .Mac est le point central où se connectent tou s
les Macs, les téléphones ne se connectent qu'à un Mac donné. Ai nsi, on
est sûr que .Mac contient la "vérité" centrale des données. Le point de
référence, quoi. Si tu n'as pas .Mac, c'est l'ordinateur qui fait o ffice
de point central.
Pour finir, pour pouvoir synchroniser A avec B, il faut un client sur A
et un serveur sur B. Les téléphones ont leur "serveur". Avec iSync, tu
as le client et tu n'as pas besoin de serveur. .Mac lui a le serveur.
Si tu veux passer outre .Mac, il te faudra une solution équivalente, et
ne t'étonne pas si tu dois la payer (un presqu'équivalent :
un serveur Exchange).
Si tu veux faire de la synchro de machine à machine, il faudra sûre ment
faire aussi des choix limitants et ça risque d'être un peu plus
compliqué à mettre en place (voir rsync alors que ce n'est que de l a
synchro de fichiers). Tout ça ne semble pas être le propos d'iSync.
Voilà, il y a des propos ironiques, en effet, mais c'est qu'on voit
souvent ce discours du "yaka" sans se rendre compte que, non, il n'y a
pas toujours "ka". Le problème, c'est que ce n'est pas toujours facil e
d'expliquer pourquoi "ilnyapaka".
Merci.
Il n'en reste pas moins que désigner un poste comme serveur devrait
rester possible. Il est dommage qu'Apple n'ait pas intégré une telle
fonctionalité (ou facilité sa mise en place). A moins que la version
"server" de Panther le fasse. Car il n'y a pas qu'Ical qui soit concerné
mais aussi le carnet d'adresse, mail, safari, IChat, etc.
Je pense en outre que ceux qui ne travaillent pas en réseau (sous Mac)
ne peuvent pas appréhender l'intérêt d'une telle synchro...
Cela dit, je pense tout de même que synchroniser deux postes devrait
faire partie des compétences d'iSync.
On peut publier un calendrier sur .mac comme on peut le faire sur un serveur WebDav ou sur un site du type icalx.com Mais on peut *aussi* synchroniser plusieurs ICal sur plusieurs machines différentes. Synchroniser signifie mettre à jour les changements le s plus récents sur tous les ICal concernés. Les modifs peuvent se faire à partir de n'importe quel ICal et se retrouver sur tous les autres. Ceci est impossible à faire sans .mac Sauf solution non officielle que j'aimerais connaitre plutôt que de subir les sarcasmes stupides que tu as pu observer :-(
Bon, je vais peut-être dire des conneries mais essayons de simplifier : En gros, la synchronisation entre A et B de données posent beaucoup d e problèmes. De nombreux conflits sont possibles, et il est compliqué de détermi ner proprement qui a raison entre A et B. Ce truc qui est sur A et pas sur B doit-il être effacé sur les deux ou ajouté à B ? Ce truc diffé rent entre A et B... lequel est la bonne version ? Et encore, ce n'est qu'entre A et B... imagine entre A, B, C, D et E... et le pire, c'est que ces zozios ne se synchronisent pas en même temps et parfois pas directement et o n pourrait imaginer que A se synchronise parfois avec B mais aussi avec E . Et puis, il se peut que quelques temps plus tard, il y ait un F qui viennent jouer avec les autres. En gros, tu dois gérer de l'informati on délocalisée, et ce n'est pas simple.
Pour avoir une synchro simple (à l'utilisation et à la configuratio n) et "sûre" (et la moins chère possible) pour l'utilisateur, il faut faire des choix techniques. Déjà, on évite tous les cycles possibles. S i tu regardes la structure, .Mac est le point central où se connectent tou s les Macs, les téléphones ne se connectent qu'à un Mac donné. Ai nsi, on est sûr que .Mac contient la "vérité" centrale des données. Le point de référence, quoi. Si tu n'as pas .Mac, c'est l'ordinateur qui fait o ffice de point central.
Pour finir, pour pouvoir synchroniser A avec B, il faut un client sur A et un serveur sur B. Les téléphones ont leur "serveur". Avec iSync, tu as le client et tu n'as pas besoin de serveur. .Mac lui a le serveur. Si tu veux passer outre .Mac, il te faudra une solution équivalente, et ne t'étonne pas si tu dois la payer (un presqu'équivalent : un serveur Exchange).
Si tu veux faire de la synchro de machine à machine, il faudra sûre ment faire aussi des choix limitants et ça risque d'être un peu plus compliqué à mettre en place (voir rsync alors que ce n'est que de l a synchro de fichiers). Tout ça ne semble pas être le propos d'iSync.
Voilà, il y a des propos ironiques, en effet, mais c'est qu'on voit souvent ce discours du "yaka" sans se rendre compte que, non, il n'y a pas toujours "ka". Le problème, c'est que ce n'est pas toujours facil e d'expliquer pourquoi "ilnyapaka".
Merci. Il n'en reste pas moins que désigner un poste comme serveur devrait rester possible. Il est dommage qu'Apple n'ait pas intégré une telle fonctionalité (ou facilité sa mise en place). A moins que la version "server" de Panther le fasse. Car il n'y a pas qu'Ical qui soit concerné mais aussi le carnet d'adresse, mail, safari, IChat, etc. Je pense en outre que ceux qui ne travaillent pas en réseau (sous Mac) ne peuvent pas appréhender l'intérêt d'une telle synchro...
Cela dit, je pense tout de même que synchroniser deux postes devrait faire partie des compétences d'iSync.
Rocou
Jérôme Lebel wrote:
Rocou wrote:
Mouais. J'aimerais comprendre pourquoi la synchro qui est si facile entre un PDA et un Mac semble tout d'un coup si complexe entre deux mac s.
Compare ce qui est comparable : peux-tu synchroniser 2 palms sans passe r par un mac ? Je ne connais pas trop les palm, mais je ne crois pas que c'est possible. Donc pourquoi voudrais-tu retirer .mac ?
Attention, je n'ai pas dit que je voulais synchroniser l'intégralité des deux macs. "Juste" Certains machins utiles à tous comme les adresses du carnet d'adresse, les rendez-vous d'iCal, etc. C'est à dire exactement ce que l'on synchronise entre un Mac et un PDA. Pas besoin de .mac dans ce cas donc je ne vois pas pourquoi il serait nécessaire entre deux Mac pour la synchro précitée.
Jérôme Lebel wrote:
Rocou <de.kat@free.fr> wrote:
Mouais. J'aimerais comprendre pourquoi la synchro qui est si facile
entre un PDA et un Mac semble tout d'un coup si complexe entre deux mac s.
Compare ce qui est comparable : peux-tu synchroniser 2 palms sans passe r
par un mac ? Je ne connais pas trop les palm, mais je ne crois pas que
c'est possible. Donc pourquoi voudrais-tu retirer .mac ?
Attention, je n'ai pas dit que je voulais synchroniser l'intégralité des
deux macs. "Juste" Certains machins utiles à tous comme les adresses du
carnet d'adresse, les rendez-vous d'iCal, etc. C'est à dire exactement
ce que l'on synchronise entre un Mac et un PDA. Pas besoin de .mac dans
ce cas donc je ne vois pas pourquoi il serait nécessaire entre deux Mac
pour la synchro précitée.
Mouais. J'aimerais comprendre pourquoi la synchro qui est si facile entre un PDA et un Mac semble tout d'un coup si complexe entre deux mac s.
Compare ce qui est comparable : peux-tu synchroniser 2 palms sans passe r par un mac ? Je ne connais pas trop les palm, mais je ne crois pas que c'est possible. Donc pourquoi voudrais-tu retirer .mac ?
Attention, je n'ai pas dit que je voulais synchroniser l'intégralité des deux macs. "Juste" Certains machins utiles à tous comme les adresses du carnet d'adresse, les rendez-vous d'iCal, etc. C'est à dire exactement ce que l'on synchronise entre un Mac et un PDA. Pas besoin de .mac dans ce cas donc je ne vois pas pourquoi il serait nécessaire entre deux Mac pour la synchro précitée.
Rocou
Georges Desort wrote:
Rocou wrote:
Olivier Goldberg wrote:
On peut publier un calendrier sur .mac comme on peut le faire sur un serveur WebDav ou sur un site du type icalx.com Mais on peut *aussi* synchroniser plusieurs ICal sur plusieurs machines différentes. Synchroniser signifie mettre à jour les changements le s plus récents sur tous les ICal concernés. Les modifs peuvent se faire à partir de n'importe quel ICal et se retrouver sur tous les autres. Ceci est impossible à faire sans .mac
Il est clair qu'iCal est "bridé" au niveau de la synchro pour contraindre les utilisateurs à utiliser .mac Ce qui se fait courament avec le couple Exchange/Outlook devrait pouvoi r se faire avec le couple iCal/WebDav Par exemple CommuniGatePro (que j'utilise pour Courriel.To) est compatible iCal, mais iCal ne permet pas la synchro, alors qu'Outlook comme client de CommuniGate la permet. J'espère que la politique d'Apple à ce sujet va changer rapidement. A+
Ha! Enfin un qui a compris :-) Merci!
Georges Desort wrote:
Rocou <de.kat@free.fr> wrote:
Olivier Goldberg wrote:
On peut publier un calendrier sur .mac comme on peut le faire sur un
serveur WebDav ou sur un site du type icalx.com
Mais on peut *aussi* synchroniser plusieurs ICal sur plusieurs machines
différentes. Synchroniser signifie mettre à jour les changements le s
plus récents sur tous les ICal concernés.
Les modifs peuvent se faire à partir de n'importe quel ICal et se
retrouver sur tous les autres.
Ceci est impossible à faire sans .mac
Il est clair qu'iCal est "bridé" au niveau de la synchro pour
contraindre les utilisateurs à utiliser .mac
Ce qui se fait courament avec le couple Exchange/Outlook devrait pouvoi r
se faire avec le couple iCal/WebDav
Par exemple CommuniGatePro (que j'utilise pour Courriel.To) est
compatible iCal, mais iCal ne permet pas la synchro, alors qu'Outlook
comme client de CommuniGate la permet.
J'espère que la politique d'Apple à ce sujet va changer rapidement.
A+
On peut publier un calendrier sur .mac comme on peut le faire sur un serveur WebDav ou sur un site du type icalx.com Mais on peut *aussi* synchroniser plusieurs ICal sur plusieurs machines différentes. Synchroniser signifie mettre à jour les changements le s plus récents sur tous les ICal concernés. Les modifs peuvent se faire à partir de n'importe quel ICal et se retrouver sur tous les autres. Ceci est impossible à faire sans .mac
Il est clair qu'iCal est "bridé" au niveau de la synchro pour contraindre les utilisateurs à utiliser .mac Ce qui se fait courament avec le couple Exchange/Outlook devrait pouvoi r se faire avec le couple iCal/WebDav Par exemple CommuniGatePro (que j'utilise pour Courriel.To) est compatible iCal, mais iCal ne permet pas la synchro, alors qu'Outlook comme client de CommuniGate la permet. J'espère que la politique d'Apple à ce sujet va changer rapidement. A+
