[sakai2-tcc] Enable shortened url service by default
Steve Swinsburg
steve.swinsburg at gmail.com
Mon Apr 2 16:26:05 PDT 2012
Thanks all. Done.
https://jira.sakaiproject.org/browse/SAK-22006
Note for clarification, I said in my original email 'even 2.9', not definitely 2.9. Obviously trunk first then iff decided, it could be backported.
cheers,
Steve
On 03/04/2012, at 6:33 AM, Aaron Zeckoski wrote:
> Sounds like a plan
> :-)
> -AZ
>
>
> On Mon, Apr 2, 2012 at 4:32 PM, Maurer, Christopher Wayne
> <chmaurer at iupui.edu> wrote:
>> If you add items to
>> config/configuration/bundles/src/bundle/org/sakaiproject/config/bundle/expe
>> rimental.sakai.properties, it should get pulled into the nightly
>> experimental build. The build script looks for that file.
>>
>> Chris
>>
>> On 4/2/12 4:27 PM, "Beth Kirschner" <bkirschn at umich.edu> wrote:
>>
>>> I may have been a bit hasty in suggesting that you "just check it in" --
>>> I think filing a JIRA that clarifies which properties you'd specifically
>>> enable (in trunk) makes sense to aid in further discussion -- Chris
>>> Maurer (chmaurer at iupui.edu) is probably the one to ask about getting
>>> these properties set up in the experimental trunk server.
>>>
>>> - Beth
>>>
>>> On Apr 2, 2012, at 3:59 PM, Beth Kirschner wrote:
>>>
>>>> I think it's a cool feature and good addition, but don't think it's a
>>>> good idea to enable it in 2.9 -- it's a slippery slope to start adding
>>>> new functionality as the release schedule slips, and I'd prefer to keep
>>>> the release in feature freeze.
>>>>
>>>> According to the confluence page
>>>> (https://confluence.sakaiproject.org/display/SHRTURL/Home), it looks
>>>> like the Resources & Portal implementations are available in trunk (aka
>>>> 2.10), and not 2.9.
>>>>
>>>> I'd suggest you create a JIRA to change the sakai.properties file to
>>>> enable the RandomisedUrlService for Resources & Portal in trunk and just
>>>> check it in. It sounds like a nice new feature for future releases. This
>>>> will put it in the nightly builds for testing. Alternately, we can
>>>> enable it in the experimental trunk server
>>>> (http://nightly2.sakaiproject.org:8085/portal) for testing, and discuss
>>>> it's promotion later (e.g. at the conference).
>>>>
>>>> - Beth
>>>>
>>>> On Mar 31, 2012, at 4:17 PM, Steve Swinsburg wrote:
>>>>
>>>>> If you later disabled it, the short urls wouldn't show up. They also
>>>>> wouldn't resolve any more, ie if you gave someone a short link then
>>>>> turned it off, the link wouldnt work, but that is a simple change if
>>>>> that was desired.
>>>>>
>>>>> Re this sort of promotion one general guideline has been the tool
>>>>> scorecard I guess but that is about promotion not activation.
>>>>>
>>>>> But this group has often proposed things for promotion/ activation,
>>>>> discussed and then voted on it. Eg java 6, tomcat 7, neoportal, portal
>>>>> chat, certain tools etc. this happened quite a lot for 2.9 and was good
>>>>> since we weren't caught up in 'paperwork' and got stuff done.
>>>>>
>>>>> Cheers
>>>>> Steve
>>>>>
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>> On 01/04/2012, at 1:45, Aaron Zeckoski <azeckoski at unicon.net> wrote:
>>>>>
>>>>>> Quick question for clarification for the group, if the property is
>>>>>> enabled and then later on disabled, do the URLs still work? In other
>>>>>> words, does turning off the option only control the UI elements
>>>>>> appearing or does it actually disable the service? Would the API calls
>>>>>> still work if the shortenedurl.implementation is commented out?
>>>>>>
>>>>>> In other words, if this is enabled by default and I discover later
>>>>>> that I did not want my faculty using it, can I turn it off?
>>>>>>
>>>>>>
>>>>>>> When you say 'Š we should probably not enable things of this
>>>>>>> natureŠ' it
>>>>>>> makes it sound like it is a huge change that affects everything, when
>>>>>>> really, it's very small, and doesn't affect anything unless a
>>>>>>> developer
>>>>>>> specifically codes for it. Like Conditional Release, you need to
>>>>>>> explicitly
>>>>>>> develop for it. It's nothing like the level of change that neoportal
>>>>>>> is, its
>>>>>>> a little service that developers can use.
>>>>>>
>>>>>> Point taken. I mostly just meant that we have loads of features which
>>>>>> are off by default. It seems odd to me to bless a few of them over the
>>>>>> others. It seems like we should have some kind of general practice
>>>>>> beyond simply "someone suggests this one be on by default now" (or
>>>>>> maybe that's good enough, I don't know).
>>>>>>
>>>>>> Not trying to pick on your request in particular (the functionality
>>>>>> seems useful) but it feels like we should define this process to some
>>>>>> degree. I would propose that only things which we are fairly confident
>>>>>> that 80% of the community wants to use should be on by default. I
>>>>>> realize that's not really prove-able or anything but it's a least a
>>>>>> rule of thumb to use when we vote on it.
>>>>>>
>>>>>> Alternatives I can think of would be "as someone suggests it" or
>>>>>> "always off by default unless it was part of the original product" or
>>>>>> "new features should always be on because people can just turn them
>>>>>> off if they like".
>>>>>>
>>>>>>
>>>>>>
>>>>>> -AZ
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Sat, Mar 31, 2012 at 10:05 AM, Steve Swinsburg
>>>>>> <steve.swinsburg at gmail.com> wrote:
>>>>>>> People knowing about it is one thing, but the main reason for the
>>>>>>> request is
>>>>>>> that it is good functionality to have. Some of our URLs are
>>>>>>> horrendously
>>>>>>> long and they can break in email clients when people copy and paste.
>>>>>>> This
>>>>>>> would improve that aspect.
>>>>>>>
>>>>>>> Also, it is only the Resources tool that really uses it (currently)
>>>>>>> and
>>>>>>> since that is a neat enhancement, I'd just ask for that one to be
>>>>>>> activated.
>>>>>>> The portal one is a much more visible so that one can stay off by
>>>>>>> default at
>>>>>>> this stage.
>>>>>>>
>>>>>>> When you say 'Š we should probably not enable things of this
>>>>>>> natureŠ' it
>>>>>>> makes it sound like it is a huge change that affects everything, when
>>>>>>> really, it's very small, and doesn't affect anything unless a
>>>>>>> developer
>>>>>>> specifically codes for it. Like Conditional Release, you need to
>>>>>>> explicitly
>>>>>>> develop for it. It's nothing like the level of change that neoportal
>>>>>>> is, its
>>>>>>> a little service that developers can use.
>>>>>>>
>>>>>>> thanks,
>>>>>>> Steve
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 01/04/2012, at 12:31 AM, Aaron Zeckoski wrote:
>>>>>>>
>>>>>>> If the issue is people knowing about it then maybe we should just
>>>>>>> send a
>>>>>>> note to sakai dev or production to make sure it is announced
>>>>>>> clearly. It
>>>>>>> already has a wiki page, is documented in the sakai properties, and
>>>>>>> I think
>>>>>>> emails have gone out before so maybe people do know about it. I'm
>>>>>>> not sure
>>>>>>> either way.
>>>>>>>
>>>>>>> I don't have much evidence other than Unicon clients and other
>>>>>>> institutions
>>>>>>> I have worked with but this seems like a niche feature based on
>>>>>>> that. If we
>>>>>>> think this is more like an 80% kind of thing then it makes sense to
>>>>>>> enable
>>>>>>> it but we should probably not enable things of this nature unless the
>>>>>>> majority of institutions want to use it. Maybe a poll of the
>>>>>>> community is in
>>>>>>> order?
>>>>>>>
>>>>>>> -AZ
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Sat, Mar 31, 2012 at 9:16 AM, Steve Swinsburg
>>>>>>> <steve.swinsburg at gmail.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I'd like to propose that we enable the Shortened Url Service by
>>>>>>>> default in
>>>>>>>> trunk (even 2.9).
>>>>>>>>
>>>>>>>> This is a service which allows people to create shortened URLs to
>>>>>>>> anything
>>>>>>>> inside Sakai, like sites, or pages, or tools, or direct to
>>>>>>>> toolstates. or
>>>>>>>> whatever.
>>>>>>>>
>>>>>>>> It is in the build but just disabled. It is activated in
>>>>>>>> sakai.properties.
>>>>>>>> I am not sure people know about it.
>>>>>>>>
>>>>>>>> Resources has support for it in the Edit Details page which is
>>>>>>>> pretty cool
>>>>>>>> (screenshots below). The portal also has a built in direct link to
>>>>>>>> tools if
>>>>>>>> people want to activate that option.
>>>>>>>>
>>>>>>>> https://confluence.sakaiproject.org/display/SHRTURL/Home
>>>>>>>>
>>>>>>>> Thoughts?
>>>>>>>>
>>>>>>>> cheers,
>>>>>>>> Steve
>>>>>>>>
>>>>>>>>
>>>>>>>> <normal.png>
>>>>>>>> <short.png>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> sakai2-tcc mailing list
>>>>>>>> sakai2-tcc at collab.sakaiproject.org
>>>>>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>>>>>>>>
>>>>>>>> --
>>>>>>>> Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> sakai2-tcc mailing list
>>>>>>> sakai2-tcc at collab.sakaiproject.org
>>>>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
>>>>> _______________________________________________
>>>>> sakai2-tcc mailing list
>>>>> sakai2-tcc at collab.sakaiproject.org
>>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>>>>
>>>
>>> _______________________________________________
>>> sakai2-tcc mailing list
>>> sakai2-tcc at collab.sakaiproject.org
>>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>>
>> _______________________________________________
>> sakai2-tcc mailing list
>> sakai2-tcc at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>
>
>
> --
> Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
More information about the sakai2-tcc
mailing list