[sakai2-tcc] Enable shortened url service by default

Maurer, Christopher Wayne chmaurer at iupui.edu
Mon Apr 2 13:32:17 PDT 2012 

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

More information about the sakai2-tcc mailing list