You are viewing a plain text version of this content. The canonical link for it is here.

Posted to user@roller.apache.org by David M Johnson <Da...@Sun.COM> on 2006/03/28 15:38:04 UTC

Moving Atom protocol(s) out of sandbox

Anybody opposed to this small re-org / refactoring?

It's late in the release cycle, but this is a change that is safe and  
has no impact on existing Roller features. The change will make my  
life easier because I won't have to maintain a separate custom  
directory for Atom protocol and Admin protocol work.


Here's what I'd like to do today:

1) Move Atom protocol implementation under package  
org.roller.webservices.atomprotocol. Add a boolean startup property  
(in roller.properties) to enable/disable it, default value is false.

2) Move Roller admin protocol implementation under package  
org.roller.webservices.adminprotocol. Add a boolean startup property  
(in roller.properties) to enable/disable, default value is false.


In case your wondering, here's some background:

* Atom protocol is a new IETF web services protocol for web  
publishing, it does the same things as MetaWeblog API and more. The  
spec is still under development and will be final this summer (I  
hope).  The Roller implementation supports the latest draft of the  
spec (draft 8):
http://bitworking.org/projects/atom/draft-ietf-atompub-protocol-08.html

* Admin protocol is a new REST based web services protocol for  
managing Roller users and blogs created by Jeff Blattman of Sun for  
Roller-Portal integration. It is based on Atom protocol and may  
someday be replaced by an IETF standard, but since admin features  
have been dropped from the current IETF Atom effort that may not  
happen for a long time, Here's Jeff's original proposal:
http://rollerweblogger.org/wiki/Wiki.jsp?page=Proposal_AAPP

- Dave

Re: Moving Atom protocol(s) out of sandbox

Posted by Dave Johnson <da...@rollerweblogger.org>.

Yes, you're right. I got that wrong. I just fixed it.

- Dave


On Mar 29, 2006, at 4:23 PM, Jeff Blattman wrote:

> dave,
>
> i noticed that the code you added for this check uses  
> RollerRuntimeConfig to get the property. if i'm not mistaken, this  
> reads properties from the database. should it have been  
> RollerConfig, to get the properties from roller[-custom].properties?
>
> thanks.
>
> David M Johnson wrote:
>
>>
>> 2) Move Roller admin protocol implementation under package   
>> org.roller.webservices.adminprotocol. Add a boolean startup  
>> property  (in roller.properties) to enable/disable, default value  
>> is false.
>>

Re: Moving Atom protocol(s) out of sandbox

Posted by Jeff Blattman <Je...@Sun.COM>.

dave,

i noticed that the code you added for this check uses 
RollerRuntimeConfig to get the property. if i'm not mistaken, this reads 
properties from the database. should it have been RollerConfig, to get 
the properties from roller[-custom].properties?

thanks.

David M Johnson wrote:

>
> 2) Move Roller admin protocol implementation under package  
> org.roller.webservices.adminprotocol. Add a boolean startup property  
> (in roller.properties) to enable/disable, default value is false.
>

Re: Moving Atom protocol(s) out of sandbox

Posted by David M Johnson <Da...@Sun.COM>.

On Mar 28, 2006, at 5:40 PM, Allen Gilliland wrote:
> David M Johnson wrote:
>> I disagree with each of your objections, but I'm not going to call  
>> for a vote on this yet because of the timing. I'll respect this as  
>> a veto. Thanks for taking a closer look at the code.
>
> I still feel that all of my objections are quite valid, but i am  
> willing to make an exception in this case and change my vote to +0  
> as long as it is clearly explained to anyone wanting to use this  
> code that these 2 services are not supported in any way and that we  
> may make any changes to them in the future, particularly changing  
> the url endpoints.

Even though I disagree, I really do appreciate and respect your  
concerns.

It was my mistake proposing this so late in the game and now I'm  
basically out of time since I'm out of the the office for the test of  
the week. So, I'll bring this up next month and add the warnings that  
you and Anil suggested to the appropriate docs.

- Dave

Re: Moving Atom protocol(s) out of sandbox

Posted by David M Johnson <Da...@Sun.COM>.

On Mar 28, 2006, at 5:52 PM, Lance Lavandowska wrote:
> I have to say that I am coming around to Allen's point, particularly
> about support.  If we release code that supports APP 0.8 are we
> binding ourselves to supporting that version for any length of time?
>
> That is, will there be any clients that may not move to 1.0, or may do
> so at a slower pace than we may like?

I really don't think that is a concern, despite the Atom format 0.3  
debacle. The only people who are implementing clients and servers now  
are doing it for interop testing. Plus, none of the "major" Roller  
sites are going to enable APP in production until it is done.

- Dave


>
> Lance
>
> On 3/28/06, Allen Gilliland <Al...@sun.com> wrote:
>>
>> David M Johnson wrote:
>>> Comments below...
>>>
>>> On Mar 28, 2006, at 3:35 PM, Allen Gilliland wrote:
>>>> David M Johnson wrote:
>>>>> On Mar 28, 2006, at 1:08 PM, Allen Gilliland wrote:
>>>>>> now that i think about it, maybe it is not a good idea to squeeze
>>>>>> this in at such a late time in the release process.
>>>>> I see that last point, but these changes are isolated to two
>>>>> Servlets, don't impact any existing features and are disabled by
>>>>> default.
>>>> yes, but the moment they go out in a release we are required to
>>>> support them forever, so we had better be sure about it.
>>>
>>> I totally disagree with that. Nothing obligates us to support this
>>> forever. And specifically for the Atom protocol, people are going to
>>> target Atom protocol 1.0, not draft 8 (which is what we now  
>>> support).
>>> The folks who target draft 8 are the folks trying to help IETF  
>>> get the
>>> protocol right (i.e. the folks in the working group).
>>>
>>> I would not propose moving out of the sandbox if I didn't think Atom
>>> protocol was stable, very near complete and ready for serious  
>>> interop
>>> testing.
>>
>> I am not saying that the protocol or the code is not stable, but I do
>> think that once we release something in a fully sanctioned Roller
>> release then we are committing to support for it.
>>
>> By support I mean that we are suggesting that we won't purposely  
>> break
>> the implementation in future releases and we will maintain some  
>> level of
>> backwards support for anyone who starts using it.  We can  
>> certainly add
>> this to the application with a warning stating that, "This feature is
>> experimental and unsupported.  Any use of this feature is subject to
>> change in the future.  If this breaks your site then it's not our  
>> fault."
>>
>> I can live with that as long as it is clearly understood by anyone  
>> who
>> tries to use it that we may make any changes to the code in the  
>> future
>> without regard for backwards compatibility or legacy support.
>>
>>>
>>>
>>>>> It would be helpful and much more convenient for me and other  
>>>>> folks
>>>>> working on this stuff to avoid the custom build setup. I really  
>>>>> don't
>>>>> think there is a downside here.
>>>> i know that's a pain, but that is not a reason to move code out  
>>>> of the
>>>> sandbox.
>>>> so, after taking a closer look at the code i think everything looks
>>>> fine, but i am still -1 on committing this to the core codebase  
>>>> right
>>>> now for 2 reasons.
>>>>
>>>> 1. as i said before, i think it is a little late in the release  
>>>> cycle
>>>> to just be throwing this in.  any code that we put in a release  
>>>> we are
>>>> responsible for, so i don't like the idea of putting this code  
>>>> in the
>>>> release if we think it's still experimental and want to keep it low
>>>> profile.
>>>
>>> I disagree with that too. I probably should not have used the word
>>> experimental.
>>>
>>> I want to get interop testing on Atom protocol and interop  
>>> testing is
>>> part of the development of the IETF Atom protocol itself. It's  
>>> harder to
>>> get people to do that testing if they have to create a custom  
>>> build to
>>> participate.
>>
>> I am fine with getting interop testing, but I don't understand how  
>> you
>> can think it's appropriate to suggest this after you have already
>> distributed 2 Roller-2.2 RCs.  To me the whole RC process suggests  
>> that
>> feature development has stopped and only bug fixes are being  
>> committed.
>>
>> I also don't consider this a particularly small addition to the code.
>> You said it's only 2 servlets, which is true, but it is still a  
>> total of
>> 28 new classes being added.  That is a lot of code to add to a  
>> release
>> during the RC process.
>>
>> I do realize that this is a somewhat special case since you are  
>> saying
>> it will be considered experimental and unsupported code, but I still
>> think we should not make it a habit to add new features to the code
>> during the RC process.  If you would have suggested this even just a
>> week ago this would be a non-issue.
>>
>>>
>>>
>>>> 2. more importantly, i think we should think more carefully  
>>>> about the
>>>> servlet endpoints we choose for these services.  we are planning to
>>>> reform the roller url structure for Roller 3.0 and i am just  
>>>> about to
>>>> send that proposal out to the dev list.  since both atom services
>>>> introduce new urls which will be affected by this change i think  
>>>> it's
>>>> better not to rush the decision to put them in the core codebase.
>>>
>>> We don't have to stick with the end points we have now, so I  
>>> disagree
>>> with this too. There are only two endpoints here, one for Atom  
>>> and one
>>> or Admin. All other URLs are discovered at runtime. Changing the
>>> endpoint URLs is really no big deal.
>>
>> Sure, it's not hard for us to do it, but I would like to think  
>> that the
>> code we put into our releases is meant to be mostly stable and not
>> likely to change that much.  The only person this really affects is
>> anyone who starts using it and distributing the urls for use on their
>> site.  Then when we change the urls those people get screwed.
>>
>> Again, I am okay with this approach so long as anyone who tries to  
>> use
>> it knows that it is likely to change in the future.  And in  
>> particular I
>> would note that it is basically assured that the urls for the service
>> endpoints will change.
>>
>>>
>>> I disagree with each of your objections, but I'm not going to  
>>> call for a
>>> vote on this yet because of the timing. I'll respect this as a veto.
>>> Thanks for taking a closer look at the code.
>>
>> I still feel that all of my objections are quite valid, but i am  
>> willing
>> to make an exception in this case and change my vote to +0 as long  
>> as it
>> is clearly explained to anyone wanting to use this code that these 2
>> services are not supported in any way and that we may make any  
>> changes
>> to them in the future, particularly changing the url endpoints.
>>
>> -- Allen
>>
>>
>>>
>>> - Dave
>>>
>>

Re: Moving Atom protocol(s) out of sandbox

Posted by Lance Lavandowska <la...@gmail.com>.

I have to say that I am coming around to Allen's point, particularly
about support.  If we release code that supports APP 0.8 are we
binding ourselves to supporting that version for any length of time?

That is, will there be any clients that may not move to 1.0, or may do
so at a slower pace than we may like?

Lance

On 3/28/06, Allen Gilliland <Al...@sun.com> wrote:
>
> David M Johnson wrote:
> > Comments below...
> >
> > On Mar 28, 2006, at 3:35 PM, Allen Gilliland wrote:
> >> David M Johnson wrote:
> >>> On Mar 28, 2006, at 1:08 PM, Allen Gilliland wrote:
> >>>> now that i think about it, maybe it is not a good idea to squeeze
> >>>> this in at such a late time in the release process.
> >>> I see that last point, but these changes are isolated to two
> >>> Servlets, don't impact any existing features and are disabled by
> >>> default.
> >> yes, but the moment they go out in a release we are required to
> >> support them forever, so we had better be sure about it.
> >
> > I totally disagree with that. Nothing obligates us to support this
> > forever. And specifically for the Atom protocol, people are going to
> > target Atom protocol 1.0, not draft 8 (which is what we now support).
> > The folks who target draft 8 are the folks trying to help IETF get the
> > protocol right (i.e. the folks in the working group).
> >
> > I would not propose moving out of the sandbox if I didn't think Atom
> > protocol was stable, very near complete and ready for serious interop
> > testing.
>
> I am not saying that the protocol or the code is not stable, but I do
> think that once we release something in a fully sanctioned Roller
> release then we are committing to support for it.
>
> By support I mean that we are suggesting that we won't purposely break
> the implementation in future releases and we will maintain some level of
> backwards support for anyone who starts using it.  We can certainly add
> this to the application with a warning stating that, "This feature is
> experimental and unsupported.  Any use of this feature is subject to
> change in the future.  If this breaks your site then it's not our fault."
>
> I can live with that as long as it is clearly understood by anyone who
> tries to use it that we may make any changes to the code in the future
> without regard for backwards compatibility or legacy support.
>
> >
> >
> >>> It would be helpful and much more convenient for me and other folks
> >>> working on this stuff to avoid the custom build setup. I really don't
> >>> think there is a downside here.
> >> i know that's a pain, but that is not a reason to move code out of the
> >> sandbox.
> >> so, after taking a closer look at the code i think everything looks
> >> fine, but i am still -1 on committing this to the core codebase right
> >> now for 2 reasons.
> >>
> >> 1. as i said before, i think it is a little late in the release cycle
> >> to just be throwing this in.  any code that we put in a release we are
> >> responsible for, so i don't like the idea of putting this code in the
> >> release if we think it's still experimental and want to keep it low
> >> profile.
> >
> > I disagree with that too. I probably should not have used the word
> > experimental.
> >
> > I want to get interop testing on Atom protocol and interop testing is
> > part of the development of the IETF Atom protocol itself. It's harder to
> > get people to do that testing if they have to create a custom build to
> > participate.
>
> I am fine with getting interop testing, but I don't understand how you
> can think it's appropriate to suggest this after you have already
> distributed 2 Roller-2.2 RCs.  To me the whole RC process suggests that
> feature development has stopped and only bug fixes are being committed.
>
> I also don't consider this a particularly small addition to the code.
> You said it's only 2 servlets, which is true, but it is still a total of
> 28 new classes being added.  That is a lot of code to add to a release
> during the RC process.
>
> I do realize that this is a somewhat special case since you are saying
> it will be considered experimental and unsupported code, but I still
> think we should not make it a habit to add new features to the code
> during the RC process.  If you would have suggested this even just a
> week ago this would be a non-issue.
>
> >
> >
> >> 2. more importantly, i think we should think more carefully about the
> >> servlet endpoints we choose for these services.  we are planning to
> >> reform the roller url structure for Roller 3.0 and i am just about to
> >> send that proposal out to the dev list.  since both atom services
> >> introduce new urls which will be affected by this change i think it's
> >> better not to rush the decision to put them in the core codebase.
> >
> > We don't have to stick with the end points we have now, so I disagree
> > with this too. There are only two endpoints here, one for Atom and one
> > or Admin. All other URLs are discovered at runtime. Changing the
> > endpoint URLs is really no big deal.
>
> Sure, it's not hard for us to do it, but I would like to think that the
> code we put into our releases is meant to be mostly stable and not
> likely to change that much.  The only person this really affects is
> anyone who starts using it and distributing the urls for use on their
> site.  Then when we change the urls those people get screwed.
>
> Again, I am okay with this approach so long as anyone who tries to use
> it knows that it is likely to change in the future.  And in particular I
> would note that it is basically assured that the urls for the service
> endpoints will change.
>
> >
> > I disagree with each of your objections, but I'm not going to call for a
> > vote on this yet because of the timing. I'll respect this as a veto.
> > Thanks for taking a closer look at the code.
>
> I still feel that all of my objections are quite valid, but i am willing
> to make an exception in this case and change my vote to +0 as long as it
> is clearly explained to anyone wanting to use this code that these 2
> services are not supported in any way and that we may make any changes
> to them in the future, particularly changing the url endpoints.
>
> -- Allen
>
>
> >
> > - Dave
> >
>

Re: Moving Atom protocol(s) out of sandbox

Posted by Allen Gilliland <Al...@Sun.COM>.

David M Johnson wrote:
> Comments below...
> 
> On Mar 28, 2006, at 3:35 PM, Allen Gilliland wrote:
>> David M Johnson wrote:
>>> On Mar 28, 2006, at 1:08 PM, Allen Gilliland wrote:
>>>> now that i think about it, maybe it is not a good idea to squeeze 
>>>> this in at such a late time in the release process.
>>> I see that last point, but these changes are isolated to two 
>>> Servlets, don't impact any existing features and are disabled by 
>>> default.
>> yes, but the moment they go out in a release we are required to 
>> support them forever, so we had better be sure about it.
> 
> I totally disagree with that. Nothing obligates us to support this 
> forever. And specifically for the Atom protocol, people are going to 
> target Atom protocol 1.0, not draft 8 (which is what we now support). 
> The folks who target draft 8 are the folks trying to help IETF get the 
> protocol right (i.e. the folks in the working group).
> 
> I would not propose moving out of the sandbox if I didn't think Atom 
> protocol was stable, very near complete and ready for serious interop 
> testing.

I am not saying that the protocol or the code is not stable, but I do 
think that once we release something in a fully sanctioned Roller 
release then we are committing to support for it.

By support I mean that we are suggesting that we won't purposely break 
the implementation in future releases and we will maintain some level of 
backwards support for anyone who starts using it.  We can certainly add 
this to the application with a warning stating that, "This feature is 
experimental and unsupported.  Any use of this feature is subject to 
change in the future.  If this breaks your site then it's not our fault."

I can live with that as long as it is clearly understood by anyone who 
tries to use it that we may make any changes to the code in the future 
without regard for backwards compatibility or legacy support.

> 
> 
>>> It would be helpful and much more convenient for me and other folks 
>>> working on this stuff to avoid the custom build setup. I really don't 
>>> think there is a downside here.
>> i know that's a pain, but that is not a reason to move code out of the 
>> sandbox.
>> so, after taking a closer look at the code i think everything looks 
>> fine, but i am still -1 on committing this to the core codebase right 
>> now for 2 reasons.
>>
>> 1. as i said before, i think it is a little late in the release cycle 
>> to just be throwing this in.  any code that we put in a release we are 
>> responsible for, so i don't like the idea of putting this code in the 
>> release if we think it's still experimental and want to keep it low 
>> profile.
> 
> I disagree with that too. I probably should not have used the word 
> experimental.
> 
> I want to get interop testing on Atom protocol and interop testing is 
> part of the development of the IETF Atom protocol itself. It's harder to 
> get people to do that testing if they have to create a custom build to 
> participate.

I am fine with getting interop testing, but I don't understand how you 
can think it's appropriate to suggest this after you have already 
distributed 2 Roller-2.2 RCs.  To me the whole RC process suggests that 
feature development has stopped and only bug fixes are being committed.

I also don't consider this a particularly small addition to the code. 
You said it's only 2 servlets, which is true, but it is still a total of 
28 new classes being added.  That is a lot of code to add to a release 
during the RC process.

I do realize that this is a somewhat special case since you are saying 
it will be considered experimental and unsupported code, but I still 
think we should not make it a habit to add new features to the code 
during the RC process.  If you would have suggested this even just a 
week ago this would be a non-issue.

> 
> 
>> 2. more importantly, i think we should think more carefully about the 
>> servlet endpoints we choose for these services.  we are planning to 
>> reform the roller url structure for Roller 3.0 and i am just about to 
>> send that proposal out to the dev list.  since both atom services 
>> introduce new urls which will be affected by this change i think it's 
>> better not to rush the decision to put them in the core codebase.
> 
> We don't have to stick with the end points we have now, so I disagree 
> with this too. There are only two endpoints here, one for Atom and one 
> or Admin. All other URLs are discovered at runtime. Changing the 
> endpoint URLs is really no big deal.

Sure, it's not hard for us to do it, but I would like to think that the 
code we put into our releases is meant to be mostly stable and not 
likely to change that much.  The only person this really affects is 
anyone who starts using it and distributing the urls for use on their 
site.  Then when we change the urls those people get screwed.

Again, I am okay with this approach so long as anyone who tries to use 
it knows that it is likely to change in the future.  And in particular I 
would note that it is basically assured that the urls for the service 
endpoints will change.

> 
> I disagree with each of your objections, but I'm not going to call for a 
> vote on this yet because of the timing. I'll respect this as a veto. 
> Thanks for taking a closer look at the code.

I still feel that all of my objections are quite valid, but i am willing 
to make an exception in this case and change my vote to +0 as long as it 
is clearly explained to anyone wanting to use this code that these 2 
services are not supported in any way and that we may make any changes 
to them in the future, particularly changing the url endpoints.

-- Allen

> 
> - Dave
>

Re: Moving Atom protocol(s) out of sandbox

Posted by David M Johnson <Da...@Sun.COM>.

Comments below...

On Mar 28, 2006, at 3:35 PM, Allen Gilliland wrote:
> David M Johnson wrote:
>> On Mar 28, 2006, at 1:08 PM, Allen Gilliland wrote:
>>> now that i think about it, maybe it is not a good idea to squeeze  
>>> this in at such a late time in the release process.
>> I see that last point, but these changes are isolated to two  
>> Servlets, don't impact any existing features and are disabled by  
>> default.
> yes, but the moment they go out in a release we are required to  
> support them forever, so we had better be sure about it.

I totally disagree with that. Nothing obligates us to support this  
forever. And specifically for the Atom protocol, people are going to  
target Atom protocol 1.0, not draft 8 (which is what we now support).  
The folks who target draft 8 are the folks trying to help IETF get  
the protocol right (i.e. the folks in the working group).

I would not propose moving out of the sandbox if I didn't think Atom  
protocol was stable, very near complete and ready for serious interop  
testing.

>> It would be helpful and much more convenient for me and other  
>> folks working on this stuff to avoid the custom build setup. I  
>> really don't think there is a downside here.
> i know that's a pain, but that is not a reason to move code out of  
> the sandbox.
> so, after taking a closer look at the code i think everything looks  
> fine, but i am still -1 on committing this to the core codebase  
> right now for 2 reasons.
>
> 1. as i said before, i think it is a little late in the release  
> cycle to just be throwing this in.  any code that we put in a  
> release we are responsible for, so i don't like the idea of putting  
> this code in the release if we think it's still experimental and  
> want to keep it low profile.

I disagree with that too. I probably should not have used the word  
experimental.

I want to get interop testing on Atom protocol and interop testing is  
part of the development of the IETF Atom protocol itself. It's harder  
to get people to do that testing if they have to create a custom  
build to participate.

> 2. more importantly, i think we should think more carefully about  
> the servlet endpoints we choose for these services.  we are  
> planning to reform the roller url structure for Roller 3.0 and i am  
> just about to send that proposal out to the dev list.  since both  
> atom services introduce new urls which will be affected by this  
> change i think it's better not to rush the decision to put them in  
> the core codebase.

We don't have to stick with the end points we have now, so I disagree  
with this too. There are only two endpoints here, one for Atom and  
one or Admin. All other URLs are discovered at runtime. Changing the  
endpoint URLs is really no big deal.

I disagree with each of your objections, but I'm not going to call  
for a vote on this yet because of the timing. I'll respect this as a  
veto. Thanks for taking a closer look at the code.

- Dave

Re: Moving Atom protocol(s) out of sandbox

Posted by Allen Gilliland <Al...@Sun.COM>.

David M Johnson wrote:
> 
> On Mar 28, 2006, at 1:08 PM, Allen Gilliland wrote:
>>
>> now that i think about it, maybe it is not a good idea to squeeze this 
>> in at such a late time in the release process.
> 
> I see that last point, but these changes are isolated to two Servlets, 
> don't impact any existing features and are disabled by default.

yes, but the moment they go out in a release we are required to support 
them forever, so we had better be sure about it.

> 
> It would be helpful and much more convenient for me and other folks 
> working on this stuff to avoid the custom build setup. I really don't 
> think there is a downside here.

i know that's a pain, but that is not a reason to move code out of the 
sandbox.

so, after taking a closer look at the code i think everything looks 
fine, but i am still -1 on committing this to the core codebase right 
now for 2 reasons.

1. as i said before, i think it is a little late in the release cycle to 
just be throwing this in.  any code that we put in a release we are 
responsible for, so i don't like the idea of putting this code in the 
release if we think it's still experimental and want to keep it low profile.

2. more importantly, i think we should think more carefully about the 
servlet endpoints we choose for these services.  we are planning to 
reform the roller url structure for Roller 3.0 and i am just about to 
send that proposal out to the dev list.  since both atom services 
introduce new urls which will be affected by this change i think it's 
better not to rush the decision to put them in the core codebase.

i think the best thing to do is to leave this out of the 2.2 release 
which is essentially finished.  as soon as we are done releasing Roller 
2.2 (late this week or early next week?) then we can move this code into 
the trunk and have it ready for the Roller 2.3 release.  we can then 
have a discussion on the list about what urls we want for the service 
endpoints.

-- Allen

> 
> - Dave
> 
>

Re: Moving Atom protocol(s) out of sandbox

Posted by David M Johnson <Da...@Sun.COM>.

On Mar 28, 2006, at 1:08 PM, Allen Gilliland wrote:
> David M Johnson wrote:
> eeks, now we are working backwards.  if these things are still  
> "experimental features" and need to be kept low profile then i am  
> -1 for moving them out of the sandbox.

> also, after "Admin protocol has had sufficient review"?  that  
> review needs to happen before we move it out of the sandbox and  
> package the code into a release.

If we're going to get help with interop testing, which is very  
important for these protocols, it would be *really* helpful to have  
these features built-in but disabled by default.

> i am okay with commiting them to the core code if the  
> implementation is complete but may have some changes in the future,  
> but we still need to treat them as if these are fully working and  
> fully functional features.  if we don't believe that is true then  
> we can't release them.
>
> now that i think about it, maybe it is not a good idea to squeeze  
> this in at such a late time in the release process.

I see that last point, but these changes are isolated to two  
Servlets, don't impact any existing features and are disabled by  
default.

It would be helpful and much more convenient for me and other folks  
working on this stuff to avoid the custom build setup. I really don't  
think there is a downside here.

- Dave

Re: Moving Atom protocol(s) out of sandbox

Posted by Allen Gilliland <Al...@Sun.COM>.

David M Johnson wrote:
> 
> On Mar 28, 2006, at 12:26 PM, Allen Gilliland wrote:
>> sounds good.  i'll wait until that's done then.
> 
> It would be helpful if you could start reviewing this stuff now, I'd 
> like to make the move before COB today (and produce another RC today) 
> since I'm out for the rest of the week.
> 
> 
>> we might want to consider making the enable/disable flags part of the 
>> runtime config rather than the static config.  it is sometimes tough 
>> to decide where certain properties should go, but these are my 
>> thoughts ..
> 
> Yes I agree, but since these are experimental features I want to keep 
> the profile low and not have them appear in the UI. Once Atom protocol 
> is final and Admin protocol has had sufficient review, I'd like to make 
> them runtime configs and document them.

eeks, now we are working backwards.  if these things are still 
"experimental features" and need to be kept low profile then i am -1 for 
moving them out of the sandbox.

also, after "Admin protocol has had sufficient review"?  that review 
needs to happen before we move it out of the sandbox and package the 
code into a release.

i am okay with commiting them to the core code if the implementation is 
complete but may have some changes in the future, but we still need to 
treat them as if these are fully working and fully functional features. 
  if we don't believe that is true then we can't release them.

now that i think about it, maybe it is not a good idea to squeeze this 
in at such a late time in the release process.

-- Allen

> 
> - Dave
>

Re: Moving Atom protocol(s) out of sandbox

Posted by David M Johnson <Da...@Sun.COM>.

On Mar 28, 2006, at 12:26 PM, Allen Gilliland wrote:
> sounds good.  i'll wait until that's done then.

It would be helpful if you could start reviewing this stuff now, I'd  
like to make the move before COB today (and produce another RC today)  
since I'm out for the rest of the week.

> we might want to consider making the enable/disable flags part of  
> the runtime config rather than the static config.  it is sometimes  
> tough to decide where certain properties should go, but these are  
> my thoughts ..

Yes I agree, but since these are experimental features I want to keep  
the profile low and not have them appear in the UI. Once Atom  
protocol is final and Admin protocol has had sufficient review, I'd  
like to make them runtime configs and document them.

- Dave

Re: Moving Atom protocol(s) out of sandbox

Posted by Allen Gilliland <Al...@Sun.COM>.

sounds good.  i'll wait until that's done then.

we might want to consider making the enable/disable flags part of the 
runtime config rather than the static config.  it is sometimes tough to 
decide where certain properties should go, but these are my thoughts ..

1. we should always try and make things configurable at runtime.

2. if a property cannot easily change at runtime then it goes in the 
static roller.properties config.  e.g. enable/disable planet features, 
or choosing roller impl.

3. if a certain property could be different per machine in a cluster, 
then it should be in the static roller.properties.  runtime properties 
affect all running instances in a cluster.  e.g. filesystem paths like 
the uploads directory.

so i think the default should be to try and make properties configurable 
at runtime since that makes them a little easier to modify.  we then 
just need to decide what properties really can't be changed at runtime 
and those are the static properties.

-- Allen

David M Johnson wrote:
> Thanks Allen.
> 
> Note that I haven't added in the disable flags and I haven't integrated 
> Jeff's latest patch. I'm working on those now.
> 
> - Dave
> 
> 
> On Mar 28, 2006, at 12:04 PM, Allen Gilliland wrote:
> 
>> I would actually like a chance to review these things first, since I 
>> have not kept up with them so far.  I will do that today and give my 
>> vote a little later.
>>
>> -- Allen
>>
>>
>> David M Johnson wrote:
>>> Anybody opposed to this small re-org / refactoring?
>>> It's late in the release cycle, but this is a change that is safe and 
>>> has no impact on existing Roller features. The change will make my 
>>> life easier because I won't have to maintain a separate custom 
>>> directory for Atom protocol and Admin protocol work.
>>> Here's what I'd like to do today:
>>> 1) Move Atom protocol implementation under package 
>>> org.roller.webservices.atomprotocol. Add a boolean startup property 
>>> (in roller.properties) to enable/disable it, default value is false.
>>> 2) Move Roller admin protocol implementation under package 
>>> org.roller.webservices.adminprotocol. Add a boolean startup property 
>>> (in roller.properties) to enable/disable, default value is false.
>>> In case your wondering, here's some background:
>>> * Atom protocol is a new IETF web services protocol for web 
>>> publishing, it does the same things as MetaWeblog API and more. The 
>>> spec is still under development and will be final this summer (I 
>>> hope).  The Roller implementation supports the latest draft of the 
>>> spec (draft 8):
>>> http://bitworking.org/projects/atom/draft-ietf-atompub-protocol-08.html
>>> * Admin protocol is a new REST based web services protocol for 
>>> managing Roller users and blogs created by Jeff Blattman of Sun for 
>>> Roller-Portal integration. It is based on Atom protocol and may 
>>> someday be replaced by an IETF standard, but since admin features 
>>> have been dropped from the current IETF Atom effort that may not 
>>> happen for a long time, Here's Jeff's original proposal:
>>> http://rollerweblogger.org/wiki/Wiki.jsp?page=Proposal_AAPP
>>> - Dave
>

Re: Moving Atom protocol(s) out of sandbox

Posted by David M Johnson <Da...@Sun.COM>.

Thanks Allen.

Note that I haven't added in the disable flags and I haven't  
integrated Jeff's latest patch. I'm working on those now.

- Dave


On Mar 28, 2006, at 12:04 PM, Allen Gilliland wrote:

> I would actually like a chance to review these things first, since  
> I have not kept up with them so far.  I will do that today and give  
> my vote a little later.
>
> -- Allen
>
>
> David M Johnson wrote:
>> Anybody opposed to this small re-org / refactoring?
>> It's late in the release cycle, but this is a change that is safe  
>> and has no impact on existing Roller features. The change will  
>> make my life easier because I won't have to maintain a separate  
>> custom directory for Atom protocol and Admin protocol work.
>> Here's what I'd like to do today:
>> 1) Move Atom protocol implementation under package  
>> org.roller.webservices.atomprotocol. Add a boolean startup  
>> property (in roller.properties) to enable/disable it, default  
>> value is false.
>> 2) Move Roller admin protocol implementation under package  
>> org.roller.webservices.adminprotocol. Add a boolean startup  
>> property (in roller.properties) to enable/disable, default value  
>> is false.
>> In case your wondering, here's some background:
>> * Atom protocol is a new IETF web services protocol for web  
>> publishing, it does the same things as MetaWeblog API and more.  
>> The spec is still under development and will be final this summer  
>> (I hope).  The Roller implementation supports the latest draft of  
>> the spec (draft 8):
>> http://bitworking.org/projects/atom/draft-ietf-atompub- 
>> protocol-08.html
>> * Admin protocol is a new REST based web services protocol for  
>> managing Roller users and blogs created by Jeff Blattman of Sun  
>> for Roller-Portal integration. It is based on Atom protocol and  
>> may someday be replaced by an IETF standard, but since admin  
>> features have been dropped from the current IETF Atom effort that  
>> may not happen for a long time, Here's Jeff's original proposal:
>> http://rollerweblogger.org/wiki/Wiki.jsp?page=Proposal_AAPP
>> - Dave

Re: Moving Atom protocol(s) out of sandbox

Posted by Allen Gilliland <Al...@Sun.COM>.

I would actually like a chance to review these things first, since I 
have not kept up with them so far.  I will do that today and give my 
vote a little later.

-- Allen


David M Johnson wrote:
> Anybody opposed to this small re-org / refactoring?
> 
> It's late in the release cycle, but this is a change that is safe and 
> has no impact on existing Roller features. The change will make my life 
> easier because I won't have to maintain a separate custom directory for 
> Atom protocol and Admin protocol work.
> 
> 
> Here's what I'd like to do today:
> 
> 1) Move Atom protocol implementation under package 
> org.roller.webservices.atomprotocol. Add a boolean startup property (in 
> roller.properties) to enable/disable it, default value is false.
> 
> 2) Move Roller admin protocol implementation under package 
> org.roller.webservices.adminprotocol. Add a boolean startup property (in 
> roller.properties) to enable/disable, default value is false.
> 
> 
> In case your wondering, here's some background:
> 
> * Atom protocol is a new IETF web services protocol for web publishing, 
> it does the same things as MetaWeblog API and more. The spec is still 
> under development and will be final this summer (I hope).  The Roller 
> implementation supports the latest draft of the spec (draft 8):
> http://bitworking.org/projects/atom/draft-ietf-atompub-protocol-08.html
> 
> * Admin protocol is a new REST based web services protocol for managing 
> Roller users and blogs created by Jeff Blattman of Sun for Roller-Portal 
> integration. It is based on Atom protocol and may someday be replaced by 
> an IETF standard, but since admin features have been dropped from the 
> current IETF Atom effort that may not happen for a long time, Here's 
> Jeff's original proposal:
> http://rollerweblogger.org/wiki/Wiki.jsp?page=Proposal_AAPP
> 
> - Dave
> 
>

Re: Moving Atom protocol(s) out of sandbox

Posted by David M Johnson <Da...@Sun.COM>.

On Mar 28, 2006, at 9:52 AM, Matt Raible wrote:
> I'm not opposed, as long as the admin protocol is secure.

If they are disabled, they will be totally secure. Both protocols  
will be disabled by default, undocumented (for now) and I'll add a  
note that it is an unsupported/experimental features.

- Dave


>
> On 3/28/06, Dave Johnson <da...@rollerweblogger.org> wrote:
>> Anybody opposed to this small re-org / refactoring?
>>
>> It's late in the release cycle, but this is a change that is safe and
>> has no impact on existing Roller features. The change will make my
>> life easier because I won't have to maintain a separate custom
>> directory for Atom protocol and Admin protocol work.
>>
>>
>> Here's what I'd like to do today:
>>
>> 1) Move Atom protocol implementation under package
>> org.roller.webservices.atomprotocol. Add a boolean startup property
>> (in roller.properties) to enable/disable it, default value is false.
>>
>> 2) Move Roller admin protocol implementation under package
>> org.roller.webservices.adminprotocol. Add a boolean startup property
>> (in roller.properties) to enable/disable, default value is false.
>>
>>
>> In case your wondering, here's some background:
>>
>> * Atom protocol is a new IETF web services protocol for web
>> publishing, it does the same things as MetaWeblog API and more. The
>> spec is still under development and will be final this summer (I
>> hope).  The Roller implementation supports the latest draft of the
>> spec (draft 8):
>> http://bitworking.org/projects/atom/draft-ietf-atompub- 
>> protocol-08.html
>>
>> * Admin protocol is a new REST based web services protocol for
>> managing Roller users and blogs created by Jeff Blattman of Sun for
>> Roller-Portal integration. It is based on Atom protocol and may
>> someday be replaced by an IETF standard, but since admin features
>> have been dropped from the current IETF Atom effort that may not
>> happen for a long time, Here's Jeff's original proposal:
>> http://rollerweblogger.org/wiki/Wiki.jsp?page=Proposal_AAPP
>>
>> - Dave
>>
>>
>>

Re: Moving Atom protocol(s) out of sandbox

Posted by Matt Raible <mr...@gmail.com>.

I'm not opposed, as long as the admin protocol is secure.

On 3/28/06, Dave Johnson <da...@rollerweblogger.org> wrote:
> Anybody opposed to this small re-org / refactoring?
>
> It's late in the release cycle, but this is a change that is safe and
> has no impact on existing Roller features. The change will make my
> life easier because I won't have to maintain a separate custom
> directory for Atom protocol and Admin protocol work.
>
>
> Here's what I'd like to do today:
>
> 1) Move Atom protocol implementation under package
> org.roller.webservices.atomprotocol. Add a boolean startup property
> (in roller.properties) to enable/disable it, default value is false.
>
> 2) Move Roller admin protocol implementation under package
> org.roller.webservices.adminprotocol. Add a boolean startup property
> (in roller.properties) to enable/disable, default value is false.
>
>
> In case your wondering, here's some background:
>
> * Atom protocol is a new IETF web services protocol for web
> publishing, it does the same things as MetaWeblog API and more. The
> spec is still under development and will be final this summer (I
> hope).  The Roller implementation supports the latest draft of the
> spec (draft 8):
> http://bitworking.org/projects/atom/draft-ietf-atompub-protocol-08.html
>
> * Admin protocol is a new REST based web services protocol for
> managing Roller users and blogs created by Jeff Blattman of Sun for
> Roller-Portal integration. It is based on Atom protocol and may
> someday be replaced by an IETF standard, but since admin features
> have been dropped from the current IETF Atom effort that may not
> happen for a long time, Here's Jeff's original proposal:
> http://rollerweblogger.org/wiki/Wiki.jsp?page=Proposal_AAPP
>
> - Dave
>
>
>

Re: Moving Atom protocol(s) out of sandbox

Posted by Anil Gangolli <an...@busybuddha.org>.

+1.

This is great.

Perhaps you should also add the background notes below to the release 
notes or docs, and add that Atom is still in IETF Draft state and to 
expect Roller implementation changes to follow spec changes along the 
standards track.

--a.


Dave Johnson wrote:
> Anybody opposed to this small re-org / refactoring?
>
> It's late in the release cycle, but this is a change that is safe and 
> has no impact on existing Roller features. The change will make my 
> life easier because I won't have to maintain a separate custom 
> directory for Atom protocol and Admin protocol work.
>
>
> Here's what I'd like to do today:
>
> 1) Move Atom protocol implementation under package 
> org.roller.webservices.atomprotocol. Add a boolean startup property 
> (in roller.properties) to enable/disable it, default value is false.
>
> 2) Move Roller admin protocol implementation under package 
> org.roller.webservices.adminprotocol. Add a boolean startup property 
> (in roller.properties) to enable/disable, default value is false.
>
>
> In case your wondering, here's some background:
>
> * Atom protocol is a new IETF web services protocol for web 
> publishing, it does the same things as MetaWeblog API and more. The 
> spec is still under development and will be final this summer (I 
> hope).  The Roller implementation supports the latest draft of the 
> spec (draft 8):
> http://bitworking.org/projects/atom/draft-ietf-atompub-protocol-08.html
>
> * Admin protocol is a new REST based web services protocol for 
> managing Roller users and blogs created by Jeff Blattman of Sun for 
> Roller-Portal integration. It is based on Atom protocol and may 
> someday be replaced by an IETF standard, but since admin features have 
> been dropped from the current IETF Atom effort that may not happen for 
> a long time, Here's Jeff's original proposal:
> http://rollerweblogger.org/wiki/Wiki.jsp?page=Proposal_AAPP
>
> - Dave
>
>
>

Re: Moving Atom protocol(s) out of sandbox

Posted by James M Snell <ja...@gmail.com>.

Please permit me to throw in a quick "woohoo!!" from the lurker
sidelines... ;-)

- James

Dave Johnson wrote:
> Anybody opposed to this small re-org / refactoring?
> 
> It's late in the release cycle, but this is a change that is safe and
> has no impact on existing Roller features. The change will make my life
> easier because I won't have to maintain a separate custom directory for
> Atom protocol and Admin protocol work.
> 
> 
> Here's what I'd like to do today:
> 
> 1) Move Atom protocol implementation under package
> org.roller.webservices.atomprotocol. Add a boolean startup property (in
> roller.properties) to enable/disable it, default value is false.
> 
> 2) Move Roller admin protocol implementation under package
> org.roller.webservices.adminprotocol. Add a boolean startup property (in
> roller.properties) to enable/disable, default value is false.
> 
> 
> In case your wondering, here's some background:
> 
> * Atom protocol is a new IETF web services protocol for web publishing,
> it does the same things as MetaWeblog API and more. The spec is still
> under development and will be final this summer (I hope).  The Roller
> implementation supports the latest draft of the spec (draft 8):
> http://bitworking.org/projects/atom/draft-ietf-atompub-protocol-08.html
> 
> * Admin protocol is a new REST based web services protocol for managing
> Roller users and blogs created by Jeff Blattman of Sun for Roller-Portal
> integration. It is based on Atom protocol and may someday be replaced by
> an IETF standard, but since admin features have been dropped from the
> current IETF Atom effort that may not happen for a long time, Here's
> Jeff's original proposal:
> http://rollerweblogger.org/wiki/Wiki.jsp?page=Proposal_AAPP
> 
> - Dave
> 
> 
>