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

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-collab message

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


Subject: Re: [office-collab] Suggestions for moving forward to resolveissues


On Thu, 2011-04-21 at 12:41 -0600, Andreas J. Guelzow wrote:
> On Thu, 2011-04-21 at 10:36 -0600, Robin LaFontaine wrote:
> 
> > A1. To resolve the issue over implementation, please could those who
> > currently feel that the GCT is impossible/difficult/expensive to
> > implement talk to those who have already done implementations? Perhaps
> > the question to answer is: what restrictions could be put in place to
> > make it easier to implement the GCT?
> 
> I have the impression that there aren't any truly independent
> implementation of this by two (or more) editing applications. While
> there appear to be two implementations they seem to have been developed
> in close cooperation (as far as this feature is concerned.).
> The difficulty I see with regard to implementation is how to adress the
> general situation when I one just encounters a valid ODF file with
> change tracking. The fact that the gct is so general a reading
> implementation would need to be able to be similarly genral when reading
> the file.

I really don't know where you got that impression from. And I mean I
*really* have no idea where.

For the record, I've not met Ganesh Paramasivam, and had absolutely no
part in KOffice's support for the GCT. Likewise, all the GCT code in
abiword was written by me, and the design to it mused entirely by me. I
have only sent Ganesh one off list email, which was to ask how to build
his KOffice branch so I could do some interoperability testing to make
my blog posts out of personal interest in interoperability.

Of course, I'd like to meet Ganesh and have few beers and a chat at some
stage. But I also extend that offer to any interesting coders ;)
	
Also, I've not contributed to the WebODF GCT implementation by Jos van
den Oever. So this makes three independent implementations, not one as
you posit. 

On your last point, if we try to avoid the GCT because of its ability to
be generic and thus choose ECT and buckets, an application then needs to
be able to generically diff ODF fragments and interpret the results to
actually work out what the changes were in order to show them. We have
merely swept the complexity out of one place and into another.




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