[sakai2-tcc] Enable shortened url service by default

Beth Kirschner bkirschn at umich.edu
Mon Apr 2 12:59:15 PDT 2012


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



More information about the sakai2-tcc mailing list