Alexandro Colorado wrote:
On Thu, Apr 16, 2009 at 4:58 AM, Florian Effenberger
<flo...@openoffice.org> wrote:
Hi Martin,
Based on the proposal
http://wiki.services.openoffice.org/wiki/ESC/Criteria_for_bundling_extensions
we got the following requirements from technical point of view:
thanks for bringing this to our attention (and sorry for my late reply).
The most important question to me is: Shall we bundle extensions at all? I
No but my thought is that we should make a GUI package manager smarter
and able to browse and get the extensions through OOo.
Firefox is the ugliest way to manage extensions, compared to KDE theme
manager is lights away from achieving a good User eXperience.
A Package manager (found in Tools->Extensions) should act as an RSS
reader and be able to 'catch' and order the extensions repository and
also be able to install with one click.
that is nothing new, we discussed this very often ... The key point is
it is still not implemented and not specified.
I think we have still a lot of open questions here in this area. And
from my point of view not enough focus in general on it.
Take for example the latest problems with the update from an already
released, probably final version to a beta version of a bundled
extension. The result was that the office crashed :-(
We have to clarify and to define how we want handle this in the future.
Should we have more repositories. One for final and stable, one for beta
and for development extensions. The extension manager would never update
a final extension from a a beta or dev repository etc. etc.
And if we implement an extensions browser to browse all available
extensions we need filters to select the repositories. Default would be
probably the final rep only.
You see a lot of things that are not clear right now and a lot of work...
But in general i agree 100%. We should use the web to bring new features
or value add to our users.
Take for example the template repository. The next logical step is to
integrate the template rep in a new template dialog that allows online
browsing. Allow bookmarking of often used or favorite templates as well
the download...
And we should make it easy for companies to configure a private inhouse
repository for templates as well as for extensions. You will find
restricted env's where the users don't have web access or only
restricted access. And from my point of view it can make really sense.
Think about a bigger deployment in a company. The inhouse repositories
would allow an easy deployment and management of company templates and
inhouse used and/or developed extensions. Probably companies don't want
that their employees can browse and can install any kind of template or
extension.
The key point is it have to be easy to use, easy to configure and
seamless for the end users.
agree to the positive effects of extensions, like developement independent
from the main code and only adding features for the user when needed - but
this also can lead to some kind of problems.
Marketing should also not bundle extension marketing with OOo like
what happened on 3.0 when we decide to push the PDF import extension
as a core part of the new version of OOo.
How shall we bundle? Via a link, so the user get the most current version
from the internet, or via file bundling? In the last case, chances are high
that the extension is already outdated when we ship it, and that the
download grows and grows without an actual need for the individual user.
Already explained but we should bundle a download manager for the most
stable extension, similar to our 'version checker' of OOo.
what are the most stable extensions? How do we mark them or select them.
We have no QA for all the extensions in the rep, we have no signed
extensions with an official and valid OO certificate that of course
would put some trust on an extension. But signing of course makes only
sense if we have some kind of QA or whatever mechanism in place to be
able to say something about the quality of an extension.
Probably a good idea to make some money for the project. ISV's can
request certification of their extensions for a some money. A well
defined group will inspect the code, will test the extension and if
everything is fine, the extension gets signed with the official OOo
certificate.
Juergen
For 3.0, we had lots of features announced that were available as extension,
like PDF import and presenter screen. Although they haven't been included in
the main download, I didn't hear many complaints about the features
"missing" from the main download.
Althought that might be true I still think is a huge liability.
I would prefer to NOT file-bundle extensions in the main download. Such kind
of bundling can easily achieved via CD/DVD distributions like our PrOOo-Box
(www.prooo-box.org). For the main download, we can link from within the
installer to our extension repository or a dedicated web site with
information on how to get more features. In terms of marketing, we should
better distinct between "features in the core" and "features via
extensions", so everyone knows what he gets.
That way, we can avoid technical problems but also keep the download size of
OOo small. Remember, we already have lots of issues with the size of our
downloads in the mirror network, so I definitely do not want to foster them
:-)
Florian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@marketing.openoffice.org
For additional commands, e-mail: dev-h...@marketing.openoffice.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@marketing.openoffice.org
For additional commands, e-mail: dev-h...@marketing.openoffice.org
