Wake up call? Nobody interested any more in this topic?
Tom
Christian Junker wrote:
Hi Tom,
great ideas and information you have here.
You define many steps, but the very first one is who would contribute and then to define a specific way of communication with each other.
If we don't have resources (people to help) we will not push anything forward, because this is not just a helper tool it is bigger than that and thus needs more than just three people.
So who else might be interested please let us know in some way.
Best Regards Christian Junker
Tom Schindl wrote:
Hi Ian,
here are my ideas about a service-page which let's you install addon-components from a internet-service you trying to build.
What I have in mind for an OO-Addon-Component installer is something like e.g. eclipse or netbeans already provide.
I. WEBSERVICE ------------- a place where people can register an addon and administrate their addons: + upload new versions, ... + modify state: pre-alpha,alpha,beta,production,oo-certified + modify compability: mark it with special flags + Versioning System: cvs or even better svn when we start from scratch + a bug-tracking system we could choose between many different ones and I'm not a friend of bugzilla maybe we could use mantis
II: INSTALLER
-------------
create an oo-addon-installer which connects to our "webservice", retrieves a list of addons + plus descriptions, ... (in worst case a csv-File, but a XML-File should not be to hard to define and Paolo is already somehow handling with XML in its codesnippet-creator)
Where can I provide help:
-------------------------
I certainly not the best one when it comes to the installer others in cc of this list are much better but I'm familiar with database/web-technologies and would provide my help on the webservice part if it is written in a language I'm familiar in (perl/java).
My choice would be Apache2.0+mod_perl2.0 but if there are many people around who are familiar using Struts and say they could make it such an Webservice-Application in less than a minute, I'm also fine.
One more thing when talking about sourceforge and oomacros. As far as I know we could also host the whole thing on sourceforge because all we need is a database and a scripting language. Sourceforge provides both for you: MySQL and PHP although PHP is a "no go" for me. I use PHP-applications but I'm not willing to write one of my own.
So what next: ------------- If other people also see it the way I do the next steps are: * Define what we need to collect on the webservice part => what info does the installer need * Define the interface between the 2 parts => define the XML-File * Start working
Tom
Ian Laurenson wrote:
This is a follow-up on the thread: http://api.openoffice.org/servlets/ReadMsg?list=dev&msgNo=11564
I now have some time to put into working on an OOo component installer, and think that an OOo component installer would be best developed by a team rather than by an individual.
My concept for an OOo component installer is along the lines of Laurent Goddard's Dictionary and Font installers. That being an autopilot approach to letting people know what components are available for download, download selected components and install them.
Currently the best repository of OOo components, that I am aware of, is http://ooomacros.org/ maintained by Russ Phillips. This site is really a front-end to SourceForge, so I am not quite sure how to go about writing a component installer that is based on this site. There were postings to this list recommending that *.services.openoffice.org might be more appropriate.
Wherever the site, my wish list for it is: * Easy for developers to upload their components and any other information that is required for the component installer to keep users informed about component options. * That users are informed of the stage of the component including the amount of peer review, this, to me, is important from a security point of view. If components remain on separate sites (like mine are now), then users need to be warned that such components might not be safe. * Assuming that this grows, it would be best if the components were mirrored so that download speeds remain acceptable.
Guidelines for component development ideally should be written. The guidelines should include information about making the components easy to translate into different languages. Being barely monolingual myself, none of my macros would be easy to translate, and I don't know the best approach for making macros/components easy to translate. Bernard Marcelly's and Laurent Goddard's approach looks good to me - a series of constant strings.
I think that the component installer should be for OOo2.0, so that it could be released as part of OOo2.0. I.e. ignore OOo1.1.x.
Associated with the component installer concept is the concept of people "voting" for components they would like with money, to encourage developers to build their component. Scenario: a company spends $100,000 a year on Microsoft Office licenses, they can't change to OOo because some certain functionality is missing. Putting up say $50,000 for the development of that component would, in the long run, be saving them significant amounts of money annually.
Has anyone else started on such a project? Comments, suggestions, alternative ideas? Anyone willing to be part of a core team to develop an OOo component installer?
Thanks, Ian Laurenson
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
