Prev: [discuss] .oxt, .xpi and .jar
Next: OpenOffice iPod App
From: Stephan Bergmann on 7 Jan 2010 04:42
On 01/06/10 22:18, Carlo Strata wrote:
> I don't know if you already discuss about this question, but I want to
> understand if native code plugins are useful or they mainly slow their
> own diffusion/adoption in all platforms...
>
> I know that OpenOffice.org needs java virtual machine to run his db
> engine (hsqldb - 100% Java Database).
>
> So why we didn't deploy all plugins in the .jar format (bytecode)?
>
> I said .xpi too in the mail's object because Mozilla too has the same
> "problem", hasn't it?
>
> The java jit (just-in-time) compiler has today very good performance so
> that if we will choose the jar way we could have no human feel with
> performance decline.
>
> In this new way, the diffusion of the extensions (plugins) for all
> platforms would be *wider* and their update *faster* for user of all
> platforms.

In case you did not know, the code in an .oxt extension can be written
in a variety of languages, including C++ (leading to native code with
all its problems you already pointed out) and Java (leading to
universally deployable extensions). The choice is up to the extension
author. Many extensions actually *are* written in Java.

-Stephan

---------------------------------------------------------------------
To unsubscribe, e-mail: discuss-unsubscribe(a)openoffice.org
For additional commands, e-mail: discuss-help(a)openoffice.org

From: Carlo Strata on 7 Jan 2010 05:26
Il 07/01/2010 10:42, Stephan Bergmann ha scritto:
> On 01/06/10 22:18, Carlo Strata wrote:
>> I don't know if you already discuss about this question, but I want to
>> understand if native code plugins are useful or they mainly slow their
>> own diffusion/adoption in all platforms...
>>
>> I know that OpenOffice.org needs java virtual machine to run his db
>> engine (hsqldb - 100% Java Database).
>>
>> So why we didn't deploy all plugins in the .jar format (bytecode)?
>>
>> I said .xpi too in the mail's object because Mozilla too has the same
>> "problem", hasn't it?
>>
>> The java jit (just-in-time) compiler has today very good performance so
>> that if we will choose the jar way we could have no human feel with
>> performance decline.
>>
>> In this new way, the diffusion of the extensions (plugins) for all
>> platforms would be *wider* and their update *faster* for user of all
>> platforms.
>
> In case you did not know, the code in an .oxt extension can be written
> in a variety of languages, including C++ (leading to native code with
> all its problems you already pointed out) and Java (leading to
> universally deployable extensions). The choice is up to the extension
> author. Many extensions actually *are* written in Java.
>
> -Stephan
>
Thank you Stephan, I should have imagined this opportunity...

But, if I have to choose an example of a non java (?) extension, I point
out the "plugin king":
http://extensions.services.openoffice.org/project/pdfimport

in which webpage you can find a list (!) of supported platform and not
only one (.oxt masked .jar) download...

This, however, to agree with your clear explanation.

Carlo

---------------------------------------------------------------------
To unsubscribe, e-mail: discuss-unsubscribe(a)openoffice.org
For additional commands, e-mail: discuss-help(a)openoffice.org

 | 
Pages: 1
Prev: [discuss] .oxt, .xpi and .jar
Next: OpenOffice iPod App