[sakai2-tcc] Enable shortened url service by default

Mon Apr 2 13:33:33 PDT 2012

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