caddyrest.blogg.se

Weatherbug for mac os 10.6
Weatherbug for mac os 10.6




weatherbug for mac os 10.6
  1. #Weatherbug for mac os 10.6 for mac os x
  2. #Weatherbug for mac os 10.6 update
  3. #Weatherbug for mac os 10.6 password

I’m been using Spotify for quite a while now, and only really listening to the music in my playlist there. Tomorrow, I’ll post about how you can make Mail.app in 10.5 and above auto-configure mail accounts for users based upon their email address (like Mail.app does for etc).Trying to get the most of out my Sonos setup with a decent streaming radio option. _submission._tcp.86400 IN SRV 0 0 587 .Īlas, nothing seems to support discovery this way yet. On a related note, I also set up SRV records for imaps, pop3s, smtp, and submission, like the following: Some more discussion on this can be found: here. I think I need to find an iOS dev (or register myself) that can look up the discovery information in the dev docs (if it’s documented). I’ve emailed a couple Apple mailing lists, and I’ll probably shoot an email or two to some Apple employee friends and see if they can point me in the right direction. I’m going to keep playing with this over the weekend, and in my free time for the next few weeks. For all we know, iOS is looking for actual data inside that caldav or carddav file in /.well-known/ rather than just a 301 to the proper location. The RFC for /.well-known/ ( here) just establishes a registry for. Thing is, I’ve tried just about every type of redirect I can figure out that redirects to, but no matter what, iOS keeps trying to login to caldav on So if it gets a 301, it doesn’t pay attention, it just keeps trying. The documentation here seems to indicate it should just redirect to the proper location. The issue is, there’s NO documentation anywhere on what that /.well-known/caldav or /.well-known/carddav file should be.

weatherbug for mac os 10.6

And if they can’t find those, it tries /, then /principals, then /principals/. They look for http(s)://(or /.well-known/carddav). The PROBLEM is that iOS (iPhone 4, 4.1, and from what I can tell, 4.2b1) don’t pay attention to SRV records, at all (Submitted bug 8447498 with Apple). _carddavs._tcp.86400 IN SRV 0 0 8843 .Īnd once again, Address Book on 10.6 magically figures it out (again, defaulting to carddavs and falling back to carddav if carddavs isn’t available). I have a similar SRV record set up for CardDAV: ICal magically figures out that my actual caldav server is (it defaults to lookup caldavs first, then caldav if caldavs isn’t available). If I tell iCal that my server is and I have an SRV records that say:

#Weatherbug for mac os 10.6 for mac os x

So, over the past few days I’ve been playing with autodiscovery of CalDAV and CardDAV for Mac OS X and iOS.Īddress Book and iCal in 10.6 use SRV records nicely.

#Weatherbug for mac os 10.6 password

Whether it’s having a file share auto-mount when they login, having to only remember a single password (or just having to login once via SSO), or in this case, not having to remember what server provides what services. Part of being a systems administrator is making the life of your customers easier. Anyway, CardDAV works, CalDAV doesn’t, but hopefully 4.3 (or whatever they call it) will fix that. Now, I have no idea why… one would think it’s the same back-end, but who knows. I’ve been told by people in the know that it’s coming, it just didn’t make it into 4.2.1.

#Weatherbug for mac os 10.6 update

UPDATE : It’s taken me a bit to post this (sorry), but I can say that iOS 4.2.1 (the released version of 4.2) supports discovery of CardDAV servers over SRV records. So all of this is now completely valid, and supported by Apple (finally)! UPDATE 2 : It’s been a year and a half (almost), but Apple finally fixed CalDAV SRV record discovery in, I believe, iOS 5.0.2 (and therefore 5.1).






Weatherbug for mac os 10.6