On 8/20/13 11:27 PM, Roberto Galoppini wrote: > 2013/8/20 Juergen Schmidt <jogischm...@gmail.com> > >> Am Dienstag, 20. August 2013 um 21:39 schrieb Roberto Galoppini: >>> 2013/8/20 Rob Weir <robw...@apache.org> >>> >>>> On Tue, Aug 20, 2013 at 11:04 AM, Jürgen Schmidt < >> jogischm...@gmail.com> >>>> wrote: >>>>> sorry for top posting >>>>> >>>>> I would like to continue the discussion on this topic because the >> user >>>>> experience is quite important here. >>>>> >>>>> What do others think and would it be possible to change it into a >> direct >>>>> download instead of the extension web page. >>>>> >>>> >>>> >>>> If we can do it over SSL then a direct update of extensions would work >>>> well. But I think that unsecured HTTP would lead to troubles. It >>>> would enable the same vulnerability we patched in AOO 4.0 related to >>>> updates of the main application. >>>> >>>> Maybe we should allow it to work either way: Extension author can >>>> specify a URL of an OXT which is installed directly, or a URL which is >>>> shown in the browser? >>>> >>>> Also, we need to remember that SourceForge is making this bandwidth >>>> available for free to extension authors who host their extensions on >>>> SF. Their business model is to have landing pages with advertising. >>>> They need to cover their expenses. That is essentially the >>>> arrangement between 3rd part extension authors and SF. But if an >>>> extension author hosts their extension elsewhere, then allowing direct >>>> download, via HTTPS, sounds good. >>>> >>> >>> >>> Let me try to tap into the conversation without my SourceForge hat on. I >>> wonder if we should pursue an indirect download strategy only for people >>> who needs to update bundled extensions and take the opportunity to tell >>> them about all the other extensions. >>> >>> I believe many AOO users don't know much about all those extensions and >> it >>> would be good to craft an indirect download page aimed at educating them. >>> >>> Another interesting possibility could be to provide end-users with >>> information about other extensions they could be interested into. Over >> the >>> last months we have been providing end-users with recommendations and the >>> results are definitely encouraging. >>> >>> Thoughts? >> that are all good ideas but not really new. >> > > No, neither I pretended them to be! :) > > Seriously, I'm talking about things SourceForge could do in a relatively > small period of time, since we'd be building on top of already existing > features. I can surely commit to do this for the project if it helps. > > Roberto >
I understand what you and back to my main concern, for me the current behaviour is a step back. For simple updates of installed extensions I don't want to be redirected to a web page. At least not from the official extension repo. Well it's always possible that extensions developers make use of this feature and insert the Url directly. But as default I don't like this. If we believe we have to promote extensions better that we should think about it. But redirecting on the web page of the already installed extension is a useless step and not necessary. Again I understand the reason behind it but I don't support it, the cost of less user experience is too high for me in this context. Juergen > > >> >> I would prefer an even closer integration in the office. For example a >> news feed on the start center presenting the highest rated extensions, the >> most downloaded one of the last 24h or based on some other selection. >> Further on allow the users to browse directly over available extensions. >> Well I know this is a completely different approach but I am more >> interested in the best user experience. >> >> Https versus http is a technical detail and can be solved easy. To >> increase security I would like to see digital signatures implemented but >> that is a different topic of course. >>> >>> Roberto >>> >>> >>> >>> >>>> >>>> Regards, >>>> >>>> -Rob >>>> >>>> >>>>> Juergen >>>>> >>>>> >>>>> On 8/16/13 10:05 AM, Oliver-Rainer Wittmann wrote: >>>>>> Hi, >>>>>> >>>>>> On 16.08.2013 09:34, Jürgen Schmidt wrote: >>>>>>> On 8/15/13 9:10 PM, Roberto Galoppini wrote: >>>>>>>> 2013/8/15 Andrea Pescetti <pesce...@apache.org> >>>>>>>> >>>>>>>>> Oliver-Rainer Wittmann wrote: >>>>>>>>> >>>>>>>>>> On 15.08.2013 12:00, Jürgen Schmidt wrote: >>>>>>>>>> >>>>>>>>>>> I noticed a changed workflow compared to former days and >> I am >>>>>>>>>>> redirected >>>>>>>>>>> now to the webpage where I can download the extension. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The update of an extension should work like the update of >> the >>>>>>>>>> extension >>>>>>>>>> "Watching Window" from 0.4.4 to 0.5.0. ... >>>>>>>>>> For the English dictionary I need to download manually the >> new >>>>>>>>>> extension. Then I need to install it manually. >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> The exception here is "Watching Window", that uses custom >> updates. >>>> The >>>>>>>>> English dictionary behaves like virtually all other >> extensions. I >>>>>>>>> give some >>>>>>>>> more details for those who are unfamiliar with the extensions >>>>>>>>> packaging. >>>>>>>>> >>>>>>>>> Whoever packaged the English dictionary back in 2010 made >> the (right) >>>>>>>>> choice to leave to the Extensions site the responsibility to >> manage >>>>>>>>> updates. "Watching Window", instead, specifies its own >> update feed, >>>>>>>>> that >>>>>>>>> lives on Github; but this is a more fragile setup; for >> example, I've >>>>>>>>> seen >>>>>>>>> countless mentions of this problem (for the OxygenOffice >> gallery >>>>>>>>> extension, >>>>>>>>> that specified its own update feed but then moved it...) >> over the >>>>>>>>> years: >>>>>>>>> >> http://forum.openoffice.org/**en/forum/viewtopic.php?f=6&t=**31360< >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> http://forum.openoffice.org/en/forum/viewtopic.php?f=6&t=31360> >>>>>>>>> >>>>>>>>> >>>>>>>>> If you specify (and host) your own update feed, you can >> choose the >>>>>>>>> update >>>>>>>>> policy (direct or indirect download); if you don't, the >> Extensions >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> site >>>>>>>>> manages everything for you and you, as the extension >> maintainer, >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> can't >>>>>>>>> choose between direct and indirect download. >>>>>>>>> >>>>>>>>> So what is under discussion here is not whether the 2010 >> maintainer >>>>>>>>> of the >>>>>>>>> English dictionary made the right choice in relying on the >> generic >>>>>>>>> update >>>>>>>>> feed (he did; otherwise I wouldn't have been able to >> republish his >>>>>>>>> extension and push updates), but is that the generic update >> feed on >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> the >>>>>>>>> Extensions site is configured to serve updates as indirect >> downloads >>>>>>>>> and >>>>>>>>> not as direct downloads. >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> The indirect download approach could be used to communicate >> with >>>>>>>> end-users >>>>>>>> through the landing pages. May be this is something we might >> want to >>>>>>>> explore to outreach our user base. >>>>>>>> >>>>>>> >>>>>>> >>>>>>> could be but I think it is not wanted in this specific context. >> The >>>> user >>>>>>> simply want the already installed and used extension get updated. >>>>>> >>>>>> >>>>>> I agree here with Jürgen. >>>>>> The user was/is already in contact with the extension website - >>>>>> otherwise she had no had the to-be-updated extension. We have the >> link >>>>>> to the extension website in the Start Center. This could be >> extended by >>>>>> something like 'news about your installed extensions' or 'other >> useful >>>>>> extensions'. >>>>>> But, here the user just wants to update an installed extension - >> having >>>>>> it 'indirectly' - as currently implemented - is a hurdle. Keep in >> mind >>>>>> that a user has typically more than one extension installed which >> is >>>>>> using the 'standard' update mechanism from the extension website >>>>>> >>>>> >>>> >>>> service. >>>>>> >>>>>> >>>>>> Best regards, Oliver. >>>>>> >>>>>>> >>>>>>> A useful enhancement to the whole managing of extensions is >> indeed the >>>>>>> possibility to browse extension online. That was planned from the >>>>>>> beginning but never realized because of some reasons that are no >> longer >>>>>>> relevant. >>>>>>> >>>>>>> The same for templates, allow easy access to the online available >>>>>>> templates, allow to mark favorites, allow offline usage of them >> etc. >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> And >>>>>>> most important make it configurable that it can be redirected to >> an >>>>>>> internal template or extension repository. Many companies want >> more >>>>>>> control about the things users can install or not >>>>>>> >>>>>>> Taking such design into account from the beginning and >> everything is >>>> fine >>>>>>> >>>>>>> Juergen >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Roberto >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Andrea. >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> >> ------------------------------**------------------------------**--------- >>>>>>>>> >>>>>>>>> To unsubscribe, e-mail: >>>>>>>>> dev-unsubscribe@openoffice.**apache.org< >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> dev-unsubscr...@openoffice.apache.org> >>>>>>>>> >>>>>>>>> For additional commands, e-mail: >> dev-h...@openoffice.apache.org >>>>>>> >>>>>>> >>>>>>> >> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >>>>>>> For additional commands, e-mail: dev-h...@openoffice.apache.org >>>>>>> >>>>>> >>>>>> >>>>>> >> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >>>>>> For additional commands, e-mail: dev-h...@openoffice.apache.org >>>>>> >>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >>>>> For additional commands, e-mail: dev-h...@openoffice.apache.org >>>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >>>> For additional commands, e-mail: dev-h...@openoffice.apache.org >>>> >>> >>> >>> >> >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
