[sakai2-tcc] Enable shortened url service by default

[Steve Swinsburg]

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