proposal for backwards compatibility issue

adam has opened bug 7948
(<https://bugzilla.osafoundation.org/show_bug.cgi?id=79
48>) which
covers the dav url backwards compatibility issue we've been
discussing.

we have never guaranteed nor made real effort to provide
backwards
compatibility for anybody other than jared and his users; we
wrote the
0.6 migration tool for him alone. i think we'd be spending
our time
incorrectly by worrying about backwards compatibility before
preview
for anybody other than jared.

as i see it, we have 3 options for solving the problem:

1) make cosmo treat /dav and /home urls as indistinguishable
from one
another. this will require refactoring of a core jcr-server
class and
will have a ripple effect throughout jcr-server and the
cosmo dav code

2) write a servlet that accepts /home requests and forwards
or
redirects them to the equivalent /dav urls. this is
essentially
re-implementing the fundamentals of mod_rewrite in java. it
adds java
code that we have to test and then maintain for some amount
of time.

3) use mod_rewrite in the reverse proxy to replace /home
with /dav in
the urls of requests proxied to cosmo.

i propose that we go with option 3. this is the simplest
solution and
is owned by osaf.us, the customer with interest in
backwards
compatibility. the recipe can easily be shared with qa for
applying to
their test environments.
_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

> adam has opened bug 7948
> (<https://bugzilla.osafoundation.org/show_bug.cgi?id=79
48>) which
> covers the dav url backwards compatibility issue we've
been
> discussing.
>
> we have never guaranteed nor made real effort to
provide backwards
> compatibility for anybody other than jared and his
users; we wrote the
> 0.6 migration tool for him alone. i think we'd be
spending our time
> incorrectly by worrying about backwards compatibility
before preview
> for anybody other than jared.
>
> as i see it, we have 3 options for solving the
problem:
>
> 1) make cosmo treat /dav and /home urls as
indistinguishable from one
> another. this will require refactoring of a core
jcr-server class and
> will have a ripple effect throughout jcr-server and the
cosmo dav code
>
> 2) write a servlet that accepts /home requests and
forwards or
> redirects them to the equivalent /dav urls. this is
essentially
> re-implementing the fundamentals of mod_rewrite in
java. it adds java
> code that we have to test and then maintain for some
amount of time.
>
> 3) use mod_rewrite in the reverse proxy to replace
/home with /dav in
> the urls of requests proxied to cosmo.
>
> i propose that we go with option 3. this is the
simplest solution and
> is owned by osaf.us, the customer with interest in
backwards
> compatibility. the recipe can easily be shared with qa
for applying to
> their test environments.

What was the reason for changing it in the first place? I
apologize  
if I failed to see this out on the list, which is likely.

And how much of a hit would it be to just change the dav
path back  
to /home until the next release?

It seems a little too late in the schedule to change
something so  
fundamental in the first place, but if it comes down to it
I'm in  
favor of option 3 above 1 and 2 at this stage in the release
as it  
will have the least code impact.

-Mikeal
_______________________________________________
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:

> What was the reason for changing it in the first place?
I apologize
> if I failed to see this out on the list, which is
likely.

to have a more explicit name that better indicates what
protocol is
used for that url namespace.

> And how much of a hit would it be to just change the
dav path back
> to /home until the next release?

very little, but why bother? we'd just have to face the same
issue then.

> It seems a little too late in the schedule to change
something so
> fundamental in the first place

i've been planning to do this for months. i talked about it
in
meetings. it's on the wiki in at least one place. i didn't
send an
explicit proposal to the list because my ideas about how to
name all
the different url spaces evolved over time, but the fact
that i
planned to make changes like this were never secret.

in reality, i thought i had done this a long time ago, but
i
discovered the other day that i had forgotten. for a couple
weeks
before that, tho, if you'd looked at the service locator
code or any
of the other new stuff i'd written, you'd have seen that the
ui, the
usd etc were generating /dav urls, not /home ones. so the
change i
made a couple days ago was just to close the loop, which i
thought i
had done well previously.

there's a stub page in the cosmo dev section of the wiki to
document
the various urls cosmo accepts. i'm going to try to get to
that this
week or next.

ps: here's another change for you. GET on a calendar
collection like
/dav/bcm/calendar/ doesn't give you the webcal document for
the
calendar anymore. it gives you an html index just like GET
on a
regular dav collection. you need to GET
/webcal/bcm/calendar/.
_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

> to have a more explicit name that better indicates what
protocol is
> used for that url namespace.

I do like it better this way, it's much more pleasing and
zen to have  
all the protocols correspond to their explicit mount
points.

> very little, but why bother? we'd just have to face the
same issue  
> then.

Well, we're forcing an update in chandler and in all the
test code,  
and I had to change the url everyone was using here at
CalConnect all  
less than a week before cosmo release.

In my opinion it should just be the first commit for 0.6.1
and 0.7,  
then we can work out any bugs we might have in interop after
this  
release.

But it's too late for that now too, so let's just leave it
so long as  
Jared can do a redirect.

> ps: here's another change for you. GET on a calendar
collection like
> /dav/bcm/calendar/ doesn't give you the webcal document
for the
> calendar anymore. it gives you an html index just like
GET on a
> regular dav collection. you need to GET
/webcal/bcm/calendar/.

Yeah, Cyrus bugged me about this today, I was going to bug
it later  
tonight. Good to know it's not actually a bug.

-Mikeal
_______________________________________________
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:

> Well, we're forcing an update in chandler and in all
the test code,
> and I had to change the url everyone was using here at
CalConnect all
> less than a week before cosmo release.

actually chandler will be using the user service document to
tell it
how to construct urls, so it's code is changing anyway ;)

bummer about calconnect. i forgot it was happening. sorry!

> Yeah, Cyrus bugged me about this today, I was going to
bug it later
> tonight. Good to know it's not actually a bug.

what was the specific issue cyrus raised? he shouldn't be
counting on
any specific behavior for GET on a calendar collection .. or
did he
simply notice that the behavior had changed?
_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

> bummer about calconnect. i forgot it was happening.
sorry!

Once I figured out what happened it wasn't too big a deal.

> what was the specific issue cyrus raised? he shouldn't
be counting on
> any specific behavior for GET on a calendar collection
.. or did he
> simply notice that the behavior had changed

Cyrus has this giant tests script that, while pretty
difficult to  
configure, tests for a huge variety of stuff. They do the
same thing  
we did and have a test for it.

As a side note, Cyrus and his test tool were the only people
who  
found bugs in the cosmo CalDAV code -- but he found quite a
few big  
ones.

-Mikeal

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

+1 assuming this is okay with Jared

On Jan 31, 2007, at 3:14 PM, Brian Moseley wrote:

> 3) use mod_rewrite in the reverse proxy to replace
/home with /dav in
> the urls of requests proxied to cosmo.
>
> i propose that we go with option 3. this is the
simplest solution and
> is owned by osaf.us, the customer with interest in
backwards
> compatibility. the recipe can easily be shared with qa
for applying to
> their test environments.

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