[sakai2-tcc] Enable shortened url service by default

Mon Apr 2 13:27:35 PDT 2012

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
> 