It's believed (through testing) that this patch removes
backwards 
compatibility for /cosmo/home/ URLs that we've said are
required to 
support an osaf.us update to 0.6 without forcing everyone to
change 
their clients all at once.

Could we get an enhancement to preserve backwards
compatibility?  Or an 
explanation of how our testing is incorrect and backwards
compatibility 
already works?

Adam's opening a bug...

Thanks.

-- Jared


-------- Original Message --------
Subject: 	[commits-cosmo] (bcm) [3520] dav paths are at
/dav, not /home
Date: 	Tue, 30 Jan 2007 11:21:03 -0800 (PST)
From: 	svncheckinosafoundation.org
To: 	commits-cosmoosafoundation.org



Revision
     3520 <http://cvs.osafoundation.org/viewcvs.cgi?rev=3
520&view=rev>
Author
     bcm
Date
     2007-01-30 11:21:03 -0800 (Tue, 30 Jan 2007)


       Log Message

dav paths are at /dav, not /home


       Modified Paths

     * 
cosmo/trunk/src/main/java/org/osaf/cosmo/dav/impl/DavCalenda
rCollection.java
      
<#cosmotrunksrcmainjavaorgosafcosmodavimplDavCalendarColl
ectionjava>
     *
cosmo/trunk/src/main/resources/applicationContext.xml
      
<#cosmotrunksrcmainresourcesapplicationContextxml>
     * cosmo/trunk/src/main/webapp/WEB-INF/web.xml
       <#cosmotrunksrcmainwebappWEBINFwebxml>


       Diff


         Modified:
 
cosmo/trunk/src/main/java/org/osaf/cosmo/dav/impl/DavCalenda
rCollection.java
         (3519 => 3520)

--- 
cosmo/trunk/src/main/java/org/osaf/cosmo/dav/impl/DavCalenda
rCollection.java 
2007-01-30 01:42:58 UTC (rev 3519)
+++ 
cosmo/trunk/src/main/java/org/osaf/cosmo/dav/impl/DavCalenda
rCollection.java 
2007-01-30 19:21:03 UTC (rev 3520)
 -98,9
+98,8 
          registerLiveProperty(MAXRESOURCESIZE);

          int cc = 
ResourceType.registerResourceType(ELEMENT_CALDAV_CALENDAR,
-                                             
NAMESPACE_CALDAV);
+                                                  
NAMESPACE_CALDAV);
          RESOURCE_TYPES = new int[] {
ResourceType.COLLECTION, cc };
-

         
DEAD_PROPERTY_FILTER.add(CalendarCollectionStamp.class.getNa
me());
      }


         Modified:
cosmo/trunk/src/main/resources/applicationContext.xml
         (3519 => 3520)

---
cosmo/trunk/src/main/resources/applicationContext.xml	2007-0
1-30 
01:42:58 UTC (rev 3519)
+++
cosmo/trunk/src/main/resources/applicationContext.xml	2007-0
1-30 
19:21:03 UTC (rev 3520)
 -474,7
+474,7 
    <bean id="davLocatorFactory"
         
class="org.osaf.cosmo.dav.impl.StandardLocatorFactory&q
uot;>
      <constructor-arg>
-      <value>/home</value>
+      <value>/dav</value>
      </constructor-arg>
      <constructor-arg>
        <value>/feed/atom/1.0</value>


         Modified:
cosmo/trunk/src/main/webapp/WEB-INF/web.xml (3519 => 
3520)

--- cosmo/trunk/src/main/webapp/WEB-INF/web.xml	2007-01-30
01:42:58 UTC 
(rev 3519)
+++ cosmo/trunk/src/main/webapp/WEB-INF/web.xml	2007-01-30
19:21:03 UTC 
(rev 3520)
 -159,7
+159,7 
    </filter-mapping>
    <filter-mapping>
      <filter-name>dav-security</filter-name>
-    <url-pattern>/home/*</url-pattern>
+    <url-pattern>/dav/*</url-pattern>
    </filter-mapping>
    <filter-mapping>
      <filter-name>dav-security</filter-name>
 -286,7
+286,7 
    </servlet-mapping>
    <servlet-mapping>
      <servlet-name>dav</servlet-name>
-    <url-pattern>/home/*</url-pattern>
+    <url-pattern>/dav/*</url-pattern>
    </servlet-mapping>
    <servlet-mapping>
      <servlet-name>cmp</servlet-name>


_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

On 1/30/07, Jared Rhine <jaredwordzoo.com> wrote:
> It's believed (through testing) that this patch removes
backwards
> compatibility for /cosmo/home/ URLs that we've said are
required to
> support an osaf.us update to 0.6 without forcing
everyone to change
> their clients all at once.
>
> Could we get an enhancement to preserve backwards
compatibility?  Or an
> explanation of how our testing is incorrect and
backwards compatibility
> already works?

no, you're right, it doesn't. i didn't recall this
backwards
compatibility requirement. is it really that big of a deal?
how many
people are actually subscribed to osaf.us calendars? is it
preferable
to put legacy code that will be removed in the next release
or to tell
the small number of people with existing subscriptions to go
make a
small tweak? i'm mildly in favor of the latter.
_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

On 1/30/07, Jared Rhine <jaredwordzoo.com> wrote:
> It's believed (through testing) that this patch removes
backwards
> compatibility for /cosmo/home/ URLs that we've said are
required to
> support an osaf.us update to 0.6 without forcing
everyone to change
> their clients all at once.
>
> Could we get an enhancement to preserve backwards
compatibility?  Or an
> explanation of how our testing is incorrect and
backwards compatibility
> already works?

no, you're right, it doesn't. i didn't recall this
backwards
compatibility requirement. is it really that big of a deal?
how many
people are actually subscribed to osaf.us calendars? is it
preferable
to put legacy code that will be removed in the next release
or to tell
the small number of people with existing subscriptions to go
make a
small tweak? i'm mildly in favor of the latter.
_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

I think Jared's original mail might have hit a lot of
peoples filters  
since it was a forward from the commits list.

In the interest of having the tests work I made some
alterations to  
the way the scripts do path referencing.

Now there is a PRINCIPAL_ROOT variable in cosmo_test_lib
that  
corresponds to the root path for the majority of test
requests. It's  
now set to '/cosmo/dav' since we've broken '/cosmo/home'.

You can easily reset it to run all the tests with a
different root  
path. During the setup_module phase the username is appended
to the  
principal root and creates a module var named
PRINCIPAL_DAV_PATH,  
which can then be used by the tests to easily find the users
 
principal dav path for dav based test -- which is all of
them except  
CMP right now.

-Mikeal


On Jan 30, 2007, at 4:46 PM, Jared Rhine wrote:

> It's believed (through testing) that this patch removes
backwards  
> compatibility for /cosmo/home/ URLs that we've said are
required to  
> support an osaf.us update to 0.6 without forcing
everyone to change  
> their clients all at once.
>
> Could we get an enhancement to preserve backwards
compatibility?   
> Or an explanation of how our testing is incorrect and
backwards  
> compatibility already works?
>
> Adam's opening a bug...
>
> Thanks.
>
> -- Jared
>
>
> -------- Original Message --------
> Subject: 	[commits-cosmo] (bcm) [3520] dav paths are at
/dav, not / 
> home
> Date: 	Tue, 30 Jan 2007 11:21:03 -0800 (PST)
> From: 	svncheckinosafoundation.org
> To: 	commits-cosmoosafoundation.org
>
>
>
> Revision
>     3520 <http://cvs.osafoundation.org/viewcvs.cgi?rev=3
520&view=rev>
> Author
>     bcm
> Date
>     2007-01-30 11:21:03 -0800 (Tue, 30 Jan 2007)
>
>
>       Log Message
>
> dav paths are at /dav, not /home
>
>
>       Modified Paths
>
>     *
cosmo/trunk/src/main/java/org/osaf/cosmo/dav/impl/ 
> DavCalendarCollection.java
>        
>
<#cosmotrunksrcmainjavaorgosafcosmodavimplDavCalendarColl
ectionjava>
>     *
cosmo/trunk/src/main/resources/applicationContext.xml
>      
<#cosmotrunksrcmainresourcesapplicationContextxml>
>     * cosmo/trunk/src/main/webapp/WEB-INF/web.xml
>       <#cosmotrunksrcmainwebappWEBINFwebxml>
>
>
>       Diff
>
>
>         Modified:
> cosmo/trunk/src/main/java/org/osaf/cosmo/dav/impl/ 
> DavCalendarCollection.java
>         (3519 => 3520)
>
> --- cosmo/trunk/src/main/java/org/osaf/cosmo/dav/impl/

> DavCalendarCollection.java 2007-01-30 01:42:58 UTC (rev
3519)
> +++ cosmo/trunk/src/main/java/org/osaf/cosmo/dav/impl/

> DavCalendarCollection.java 2007-01-30 19:21:03 UTC (rev
3520)
>  -98,9 +98,8 
>          registerLiveProperty(MAXRESOURCESIZE);
>
>          int cc = ResourceType.registerResourceType 
> (ELEMENT_CALDAV_CALENDAR,
> -                                             
NAMESPACE_CALDAV);
> +                                                  
NAMESPACE_CALDAV);
>          RESOURCE_TYPES = new int[] {
ResourceType.COLLECTION, cc };
> -
>
>          DEAD_PROPERTY_FILTER.add 
> (CalendarCollectionStamp.class.getName());
>      }
>
>
>         Modified: cosmo/trunk/src/main/resources/ 
> applicationContext.xml
>         (3519 => 3520)
>
> ---
cosmo/trunk/src/main/resources/applicationContext.xml	 
> 2007-01-30 01:42:58 UTC (rev 3519)
> +++
cosmo/trunk/src/main/resources/applicationContext.xml	 
> 2007-01-30 19:21:03 UTC (rev 3520)
>  -474,7 +474,7 
>    <bean id="davLocatorFactory"
>         
class="org.osaf.cosmo.dav.impl.StandardLocatorFactory&q
uot;>
>      <constructor-arg>
> -      <value>/home</value>
> +      <value>/dav</value>
>      </constructor-arg>
>      <constructor-arg>
>        <value>/feed/atom/1.0</value>
>
>
>         Modified:
cosmo/trunk/src/main/webapp/WEB-INF/web.xml (3519  
> => 3520)
>
> ---
cosmo/trunk/src/main/webapp/WEB-INF/web.xml	2007-01-30
01:42:58  
> UTC (rev 3519)
> +++
cosmo/trunk/src/main/webapp/WEB-INF/web.xml	2007-01-30
19:21:03  
> UTC (rev 3520)
>  -159,7 +159,7 
>    </filter-mapping>
>    <filter-mapping>
>     
<filter-name>dav-security</filter-name>
> -    <url-pattern>/home/*</url-pattern>
> +    <url-pattern>/dav/*</url-pattern>
>    </filter-mapping>
>    <filter-mapping>
>     
<filter-name>dav-security</filter-name>
>  -286,7 +286,7 
>    </servlet-mapping>
>    <servlet-mapping>
>      <servlet-name>dav</servlet-name>
> -    <url-pattern>/home/*</url-pattern>
> +    <url-pattern>/dav/*</url-pattern>
>    </servlet-mapping>
>    <servlet-mapping>
>      <servlet-name>cmp</servlet-name>
>
> <file:___tmp_nsmail.txt>
> _______________________________________________
> cosmo-dev mailing list
> cosmo-devlists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

I think Jared's original mail might have hit a lot of
peoples filters  
since it was a forward from the commits list.

In the interest of having the tests work I made some
alterations to  
the way the scripts do path referencing.

Now there is a PRINCIPAL_ROOT variable in cosmo_test_lib
that  
corresponds to the root path for the majority of test
requests. It's  
now set to '/cosmo/dav' since we've broken '/cosmo/home'.

You can easily reset it to run all the tests with a
different root  
path. During the setup_module phase the username is appended
to the  
principal root and creates a module var named
PRINCIPAL_DAV_PATH,  
which can then be used by the tests to easily find the users
 
principal dav path for dav based test -- which is all of
them except  
CMP right now.

-Mikeal


On Jan 30, 2007, at 4:46 PM, Jared Rhine wrote:

> It's believed (through testing) that this patch removes
backwards  
> compatibility for /cosmo/home/ URLs that we've said are
required to  
> support an osaf.us update to 0.6 without forcing
everyone to change  
> their clients all at once.
>
> Could we get an enhancement to preserve backwards
compatibility?   
> Or an explanation of how our testing is incorrect and
backwards  
> compatibility already works?
>
> Adam's opening a bug...
>
> Thanks.
>
> -- Jared
>
>
> -------- Original Message --------
> Subject: 	[commits-cosmo] (bcm) [3520] dav paths are at
/dav, not / 
> home
> Date: 	Tue, 30 Jan 2007 11:21:03 -0800 (PST)
> From: 	svncheckinosafoundation.org
> To: 	commits-cosmoosafoundation.org
>
>
>
> Revision
>     3520 <http://cvs.osafoundation.org/viewcvs.cgi?rev=3
520&view=rev>
> Author
>     bcm
> Date
>     2007-01-30 11:21:03 -0800 (Tue, 30 Jan 2007)
>
>
>       Log Message
>
> dav paths are at /dav, not /home
>
>
>       Modified Paths
>
>     *
cosmo/trunk/src/main/java/org/osaf/cosmo/dav/impl/ 
> DavCalendarCollection.java
>        
>
<#cosmotrunksrcmainjavaorgosafcosmodavimplDavCalendarColl
ectionjava>
>     *
cosmo/trunk/src/main/resources/applicationContext.xml
>      
<#cosmotrunksrcmainresourcesapplicationContextxml>
>     * cosmo/trunk/src/main/webapp/WEB-INF/web.xml
>       <#cosmotrunksrcmainwebappWEBINFwebxml>
>
>
>       Diff
>
>
>         Modified:
> cosmo/trunk/src/main/java/org/osaf/cosmo/dav/impl/ 
> DavCalendarCollection.java
>         (3519 => 3520)
>
> --- cosmo/trunk/src/main/java/org/osaf/cosmo/dav/impl/

> DavCalendarCollection.java 2007-01-30 01:42:58 UTC (rev
3519)
> +++ cosmo/trunk/src/main/java/org/osaf/cosmo/dav/impl/

> DavCalendarCollection.java 2007-01-30 19:21:03 UTC (rev
3520)
>  -98,9 +98,8 
>          registerLiveProperty(MAXRESOURCESIZE);
>
>          int cc = ResourceType.registerResourceType 
> (ELEMENT_CALDAV_CALENDAR,
> -                                             
NAMESPACE_CALDAV);
> +                                                  
NAMESPACE_CALDAV);
>          RESOURCE_TYPES = new int[] {
ResourceType.COLLECTION, cc };
> -
>
>          DEAD_PROPERTY_FILTER.add 
> (CalendarCollectionStamp.class.getName());
>      }
>
>
>         Modified: cosmo/trunk/src/main/resources/ 
> applicationContext.xml
>         (3519 => 3520)
>
> ---
cosmo/trunk/src/main/resources/applicationContext.xml	 
> 2007-01-30 01:42:58 UTC (rev 3519)
> +++
cosmo/trunk/src/main/resources/applicationContext.xml	 
> 2007-01-30 19:21:03 UTC (rev 3520)
>  -474,7 +474,7 
>    <bean id="davLocatorFactory"
>         
class="org.osaf.cosmo.dav.impl.StandardLocatorFactory&q
uot;>
>      <constructor-arg>
> -      <value>/home</value>
> +      <value>/dav</value>
>      </constructor-arg>
>      <constructor-arg>
>        <value>/feed/atom/1.0</value>
>
>
>         Modified:
cosmo/trunk/src/main/webapp/WEB-INF/web.xml (3519  
> => 3520)
>
> ---
cosmo/trunk/src/main/webapp/WEB-INF/web.xml	2007-01-30
01:42:58  
> UTC (rev 3519)
> +++
cosmo/trunk/src/main/webapp/WEB-INF/web.xml	2007-01-30
19:21:03  
> UTC (rev 3520)
>  -159,7 +159,7 
>    </filter-mapping>
>    <filter-mapping>
>     
<filter-name>dav-security</filter-name>
> -    <url-pattern>/home/*</url-pattern>
> +    <url-pattern>/dav/*</url-pattern>
>    </filter-mapping>
>    <filter-mapping>
>     
<filter-name>dav-security</filter-name>
>  -286,7 +286,7 
>    </servlet-mapping>
>    <servlet-mapping>
>      <servlet-name>dav</servlet-name>
> -    <url-pattern>/home/*</url-pattern>
> +    <url-pattern>/dav/*</url-pattern>
>    </servlet-mapping>
>    <servlet-mapping>
>      <servlet-name>cmp</servlet-name>
>
> <file:___tmp_nsmail.txt>
> _______________________________________________
> cosmo-dev mailing list
> cosmo-devlists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

Or, is this something that could be solved at the Apache
config level?
On Jan 30, 2007, at 4:20 PM, Brian Moseley wrote:

> On 1/30/07, Jared Rhine <jaredwordzoo.com> wrote:
>> It's believed (through testing) that this patch
removes backwards
>> compatibility for /cosmo/home/ URLs that we've said
are required to
>> support an osaf.us update to 0.6 without forcing
everyone to change
>> their clients all at once.
>>
>> Could we get an enhancement to preserve backwards
compatibility?   
>> Or an
>> explanation of how our testing is incorrect and
backwards  
>> compatibility
>> already works?
>
> no, you're right, it doesn't. i didn't recall this
backwards
> compatibility requirement. is it really that big of a
deal? how many
> people are actually subscribed to osaf.us calendars? is
it preferable
> to put legacy code that will be removed in the next
release or to tell
> the small number of people with existing subscriptions
to go make a
> small tweak? i'm mildly in favor of the latter.
> _______________________________________________
> cosmo-dev mailing list
> cosmo-devlists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

Can we please try to keep the amount of redirections we do
with  
apache to a minimum.

It increases the amount of issues we find between release  
certification and production staging.

-Mikeal

On Jan 31, 2007, at 11:40 AM, Bobby Rullo wrote:

> Or, is this something that could be solved at the
Apache config level?
> On Jan 30, 2007, at 4:20 PM, Brian Moseley wrote:
>
>> On 1/30/07, Jared Rhine <jaredwordzoo.com> wrote:
>>> It's believed (through testing) that this patch
removes backwards
>>> compatibility for /cosmo/home/ URLs that we've
said are required to
>>> support an osaf.us update to 0.6 without
forcing everyone to change
>>> their clients all at once.
>>>
>>> Could we get an enhancement to preserve
backwards compatibility?   
>>> Or an
>>> explanation of how our testing is incorrect and
backwards  
>>> compatibility
>>> already works?
>>
>> no, you're right, it doesn't. i didn't recall this
backwards
>> compatibility requirement. is it really that big of
a deal? how many
>> people are actually subscribed to osaf.us
calendars? is it preferable
>> to put legacy code that will be removed in the next
release or to  
>> tell
>> the small number of people with existing
subscriptions to go make a
>> small tweak? i'm mildly in favor of the latter.
>> _______________________________________________
>> cosmo-dev mailing list
>> cosmo-devlists.osafoundation.org
>> http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev
>
> _______________________________________________
> cosmo-dev mailing list
> cosmo-devlists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

On 1/31/07, Mikeal Rogers <mikealosafoundation.org>
wrote:
> Can we please try to keep the amount of redirections we
do with
> apache to a minimum.
>
> It increases the amount of issues we find between
release
> certification and production staging.

on the other hand, it saves us from putting code into the
server that
1) has the potential for unintended side effects and 2) has
to be
removed in the future for what is essentially an issue at a
single
point in time that affects a relatively small number of
people.

if this really can be solved with some apache rewrites (and
i leave it
to jared to tell us if that's true), than that approach gets
my vote.
_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

Or, is this something that could be solved at the Apache
config level?
On Jan 30, 2007, at 4:20 PM, Brian Moseley wrote:

> On 1/30/07, Jared Rhine <jaredwordzoo.com> wrote:
>> It's believed (through testing) that this patch
removes backwards
>> compatibility for /cosmo/home/ URLs that we've said
are required to
>> support an osaf.us update to 0.6 without forcing
everyone to change
>> their clients all at once.
>>
>> Could we get an enhancement to preserve backwards
compatibility?   
>> Or an
>> explanation of how our testing is incorrect and
backwards  
>> compatibility
>> already works?
>
> no, you're right, it doesn't. i didn't recall this
backwards
> compatibility requirement. is it really that big of a
deal? how many
> people are actually subscribed to osaf.us calendars? is
it preferable
> to put legacy code that will be removed in the next
release or to tell
> the small number of people with existing subscriptions
to go make a
> small tweak? i'm mildly in favor of the latter.
> _______________________________________________
> cosmo-dev mailing list
> cosmo-devlists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

Can we please try to keep the amount of redirections we do
with  
apache to a minimum.

It increases the amount of issues we find between release  
certification and production staging.

-Mikeal

On Jan 31, 2007, at 11:40 AM, Bobby Rullo wrote:

> Or, is this something that could be solved at the
Apache config level?
> On Jan 30, 2007, at 4:20 PM, Brian Moseley wrote:
>
>> On 1/30/07, Jared Rhine <jaredwordzoo.com> wrote:
>>> It's believed (through testing) that this patch
removes backwards
>>> compatibility for /cosmo/home/ URLs that we've
said are required to
>>> support an osaf.us update to 0.6 without
forcing everyone to change
>>> their clients all at once.
>>>
>>> Could we get an enhancement to preserve
backwards compatibility?   
>>> Or an
>>> explanation of how our testing is incorrect and
backwards  
>>> compatibility
>>> already works?
>>
>> no, you're right, it doesn't. i didn't recall this
backwards
>> compatibility requirement. is it really that big of
a deal? how many
>> people are actually subscribed to osaf.us
calendars? is it preferable
>> to put legacy code that will be removed in the next
release or to  
>> tell
>> the small number of people with existing
subscriptions to go make a
>> small tweak? i'm mildly in favor of the latter.
>> _______________________________________________
>> cosmo-dev mailing list
>> cosmo-devlists.osafoundation.org
>> http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev
>
> _______________________________________________
> cosmo-dev mailing list
> cosmo-devlists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

On 1/31/07, Mikeal Rogers <mikealosafoundation.org>
wrote:
> Can we please try to keep the amount of redirections we
do with
> apache to a minimum.
>
> It increases the amount of issues we find between
release
> certification and production staging.

on the other hand, it saves us from putting code into the
server that
1) has the potential for unintended side effects and 2) has
to be
removed in the future for what is essentially an issue at a
single
point in time that affects a relatively small number of
people.

if this really can be solved with some apache rewrites (and
i leave it
to jared to tell us if that's true), than that approach gets
my vote.
_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

Have we just taken people who are running cosmo at home off
of our  
supported user list?

Is this a case where users of the hosted service are going
to care  
deeply and home users won't at all? I would imagine both
sets of  
users are impacted equally.

-Mikeal

On Jan 31, 2007, at 11:53 AM, Brian Moseley wrote:

> On 1/31/07, Mikeal Rogers <mikealosafoundation.org> wrote:
>> Can we please try to keep the amount of
redirections we do with
>> apache to a minimum.
>>
>> It increases the amount of issues we find between
release
>> certification and production staging.
>
> on the other hand, it saves us from putting code into
the server that
> 1) has the potential for unintended side effects and 2)
has to be
> removed in the future for what is essentially an issue
at a single
> point in time that affects a relatively small number of
people.
>
> if this really can be solved with some apache rewrites
(and i leave it
> to jared to tell us if that's true), than that approach
gets my vote.
> _______________________________________________
> cosmo-dev mailing list
> cosmo-devlists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

Have we just taken people who are running cosmo at home off
of our  
supported user list?

Is this a case where users of the hosted service are going
to care  
deeply and home users won't at all? I would imagine both
sets of  
users are impacted equally.

-Mikeal

On Jan 31, 2007, at 11:53 AM, Brian Moseley wrote:

> On 1/31/07, Mikeal Rogers <mikealosafoundation.org> wrote:
>> Can we please try to keep the amount of
redirections we do with
>> apache to a minimum.
>>
>> It increases the amount of issues we find between
release
>> certification and production staging.
>
> on the other hand, it saves us from putting code into
the server that
> 1) has the potential for unintended side effects and 2)
has to be
> removed in the future for what is essentially an issue
at a single
> point in time that affects a relatively small number of
people.
>
> if this really can be solved with some apache rewrites
(and i leave it
> to jared to tell us if that's true), than that approach
gets my vote.
> _______________________________________________
> cosmo-dev mailing list
> cosmo-devlists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

On 1/31/07, Mikeal Rogers <mikealosafoundation.org>
wrote:
> Have we just taken people who are running cosmo at home
off of our
> supported user list?
>
> Is this a case where users of the hosted service are
going to care
> deeply and home users won't at all? I would imagine
both sets of
> users are impacted equally.

i don't think the dozen or so extremely early adopters who
feel
comfortable running pre-release software aren't going to
have a cow
about this.

remember the version number guys 
_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

On 1/31/07, Mikeal Rogers <mikealosafoundation.org>
wrote:
> Have we just taken people who are running cosmo at home
off of our
> supported user list?
>
> Is this a case where users of the hosted service are
going to care
> deeply and home users won't at all? I would imagine
both sets of
> users are impacted equally.

i don't think the dozen or so extremely early adopters who
feel
comfortable running pre-release software aren't going to
have a cow
about this.

remember the version number guys 
_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

On 1/31/07, Jeffrey Harris <jeffreyosafoundation.org>
wrote:

> Regardless of the version, there definitely are
Chandler dogfooders who
> will be seriously inconvenienced if we change the URLs
to collections.
> I don't know if that's enough reason to avoid this,
perhaps on osaf.us
> we can do URL rewriting, but I'll add weight to this
being a real issue
> for Chandler dogfooders.

i don't understand the inconvenience. can't you just open
the
collection details dialog and change the path?
_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

On Jan 31, 2007, at 11:31 AM, Brian Moseley wrote:

> On 1/31/07, Jeffrey Harris <jeffreyosafoundation.org> wrote:
>
>> Regardless of the version, there definitely are
Chandler  
>> dogfooders who
>> will be seriously inconvenienced if we change the
URLs to  
>> collections.
>> I don't know if that's enough reason to avoid this,
perhaps on  
>> osaf.us
>> we can do URL rewriting, but I'll add weight to
this being a real  
>> issue
>> for Chandler dogfooders.
>
> i don't understand the inconvenience. can't you just
open the
> collection details dialog and change the path?

Do you mean in Chandler?

Chandler currently has no affordances for the user to change
the path  
of a collection that was subscribed to via url+ticket.  For
a  
collection that the user published (or subscribed to via
basic auth),  
modifying the corresponding account's path in the Chandler
account  
dialog will effectively change the paths for all collections
 
associated with that account.

_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

On 1/31/07, Morgen Sagen <morgenosafoundation.org>
wrote:

> Chandler currently has no affordances for the user to
change the path
> of a collection that was subscribed to via url+ticket.

if chandler was trying to sync to one of these urls and got
a 302
instead of a 200 (or 207 or whatever the expectation is),
would it
follow the 302?
_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

On Jan 31, 2007, at 12:05 PM, Brian Moseley wrote:

> On 1/31/07, Morgen Sagen <morgenosafoundation.org> wrote:
>
>> Chandler currently has no affordances for the user
to change the path
>> of a collection that was subscribed to via
url+ticket.
>
> if chandler was trying to sync to one of these urls and
got a 302
> instead of a 200 (or 207 or whatever the expectation
is), would it
> follow the 302?

Looks like Zanshin (the networking library Chandler uses)
will follow  
a 302, so *conceivably* a Chandler that's subscribed to a
collection  
via a URL like this...

    http://<hostname>/cosmo/home/&l
t;username>/<collectionname>? 
ticket=<ticket>

...would be none the wiser as long as every request Chandler
makes to  
that URL (and all child resources of that URL) are 302'd to
the right  
place.  Conceivably.





_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

On Jan 31, 2007, at 12:05 PM, Brian Moseley wrote:

> On 1/31/07, Morgen Sagen <morgenosafoundation.org> wrote:
>
>> Chandler currently has no affordances for the user
to change the path
>> of a collection that was subscribed to via
url+ticket.
>
> if chandler was trying to sync to one of these urls and
got a 302
> instead of a 200 (or 207 or whatever the expectation
is), would it
> follow the 302?

Looks like Zanshin (the networking library Chandler uses)
will follow  
a 302, so *conceivably* a Chandler that's subscribed to a
collection  
via a URL like this...

    http://<hostname>/cosmo/home/&l
t;username>/<collectionname>? 
ticket=<ticket>

...would be none the wiser as long as every request Chandler
makes to  
that URL (and all child resources of that URL) are 302'd to
the right  
place.  Conceivably.





_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev