[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