[Cosmo-dev] Re: [Dev] Re: [Cosmo] Apple iCal & cosmo-demo

[Charles Wyble]

Can you clarify option 1? No HTTPS at all or no HTTPS for iCAL? If no 
HTTPS for iCAL how would Cosmo know it is serving an iCAL client? And 
then would it issue a re direct for every CalDAV call made my the 
client? This seems to be very resource intensive.
As for not having HTTPS at all, I would think that not having HTTPS 
would be a detractor to cosmo adoption as a public (ie in the DMZ) service.

Option 2 means that any changes you do have to be done three times. Or 
at least I am assuming that not having looked to deeply into the code. 
As someone mentioned earlier on this thread, having this multiple client 
issue is like all the pain of supporting multiple browsers.
Also I don't know if having 3 urls is even a viable option. Someone more 
familiar with Cosmo will need to speak to that.

Just my 2 cents. :)




Sheila Mooney wrote:
> So it looks like we have a couple of options if we want to make this 
> work.
>
> 1. We could just do http and not https.
> 2. We could continue to offer access over http, and give users 3 urls, 
> 1 for ical specifically.
>
> Could someone comment on the technical tradeoffs for both solutions? 
> For example, what is the downside if we use http (port 80) rather than 
> https?
>
> Thanks,
> Sheila
>
> On Mar 7, 2006, at 10:49 AM, Morgen Sagen wrote:
>
>>
>> On Mar 7, 2006, at 9:31 AM, Charles Wyble wrote:
>>
>>>
>>>
>>> Lisa Dusseault wrote:
>>>>
>>>> On Mar 6, 2006, at 12:17 PM, Morgen Sagen wrote:
>>>>
>>>>> I don't think Chandler should assume that there will be a port 80 
>>>>> ('http') server along with the port 443 ('https') server, and that 
>>>>> they both refer to the same Cosmo instance.  I'm not sure how 
>>>>> Chandler could know this in a general way, without having 
>>>>> site-specific logic (in other words, "if host == 'cosmo-demo' then 
>>>>> port 443 is equivalent to 80") inside Chandler.  It's perhaps 
>>>>> unusual that cosmo-demo is set up this way, and I wouldn't count 
>>>>> on it.  I would be interested to hear what other people think.
>>> Well this isn't entirely true. Its not Chandler thats the problem 
>>> but Apple ICAL. They evidently don't support https. So the logic 
>>> would actually need to be inside Cosmo no? To detect the client and 
>>> do different things.
>>
>> Well, yes and no.  It affects Chandler because we have a feature 
>> which allows you to copy a shared collection's URL to the clipboard 
>> so that you can paste it into either an email message (to invite 
>> someone to subscribe) or to another client (such as iCal).  The 
>> original question was if Chandler could somehow generate the 'iCal 
>> friendly' URL in this situation, and I think it's unfortunately 'no' 
>> since it's unlikely there *will* be such a non-HTTPS URL (although 
>> there happens to be one now on cosmo-demo, which was news to me).
>>
>> It is really unfortunate Apple removed HTTPS support for iCal (which 
>> apparently happened quite recently).  I guess we have to ask 
>> ourselves if we want to just use regular HTTP (port 80) rather than 
>> HTTPS.
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> Open Source Applications Foundation "Dev" mailing list
>> http://lists.osafoundation.org/mailman/listinfo/dev
>