OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [office-comment] Interface META-Functions


Hi Thomas,

Thomas Zander wrote:
> On Saturday 09 June 2007 13:31:52 Leonard Mada wrote:
>   
>> However, it is difficult to implement every function inside the
>> spreadsheet application, especially as complex functions are not
>> trivial to implement.
>>
>> This is even NOT necessary, because often advanced open source programs
>> do exist which fill the gap.
>>
>> However, what is lacking is *a standardized way * to communicate to
>> these external programs.
>>     
>
> Hmm, i was under the impression that ODF was _the_ way to communicate to 
> these external programs.
> Send the data in an (small) spread sheet file to the external application 
> and get the results back in a similar file.
>
> This 'file' could naturally also be sent either via an inter-process 
> communication method or even via the clipboard.
>
> This, at least, is what KDe as a whole desktop environment is moving 
> towards to allow lots of small apps do its own thing and communicate 
> using the standardized format that is open document.
>
> Won't that solve the issue you brought up here?
>   

I envision three unsurmountable problems with this approach:
[There existed 'csv' before, so the problem is NOT new! I still usually 
import spreadsheet files through an intermediary csv file in R and then 
make the statistical analysis in R. Though this is time consuming, and 
IF I detect an error and need to correct the initial spreadsheet, this 
becomes a nuisance, too.]

 1.) you can NOT force every program developer to support ODF,
      or to support it fully and completely, e.g.:
          - it MUST support ALL functions of the spreadsheet application
          - additional complication IF 2 or more external programs are used:
              -- cell A1 computed by program 'A'
              -- used by program 'B' to compute cell B1
              -- propensity for major errors, especially IF:
                      order of execution of programs is changed
                      programs have to be called multiple times
                      cell range sent to the external application 
contains also cells  that need to be recalculated,
                      but can so only by a third program

 2.) you will need to work (simultaneously) in multiple programs

 3.) updating the cells (after one cell has been corrected) will be a 
catastrophy;
      - it is even impossible to implement  a mechanism which will tell 
the user that
       some cells are NOT updated, as the spreadsheet program can NOT know
       how those cells were computed using the external application

Of course, IF the spreadsheet program acts as a server that presents the 
data to the external applications, some of these problems are solved, 
BUT then this solution is closer to my proposal, and there still remain 
some problems discussed especially at points 1.) and 2.).

Hope this clarifies some of the problems.

Regards,

Leonard


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]