shiny uno version, Desktop IDL

[Stephan Bergmann]

[adding the ML into the loop; hope you don't mind]

On 06/13/2012 12:08 PM, Noel Grandin wrote:
> On 2012-06-12 19:07, Stephan Bergmann wrote:
>> On 06/12/2012 06:22 PM, Noel Grandin wrote:
>>> I'm looking at converting the various places that call
>>> createInstance("com.sun.star.frame.Desktop")
>>> to use a factory method.
>>>
>>> I notice that the Desktop IDL looks like
>>> published service Desktop
>>> {
>>> service Frame;
>>> interface XDesktop;
>>> interface XComponentLoader;
>>> interface com::sun::star::document::XEventBroadcaster;
>>> }
>>>
>>> What is the process here? Do I convert Desktop to extend all of the
>>> interfaces? Or just one? Or do I create new factory methods?
>>
>> Technically, a new interface inheriting from all the other interfaces
>> would need to be introduced, and the service would need to be changed
>> to implement that single interface instead. But that is considered too
>> incompatible to do before LO 4.
>>
>>
>
> How about if I introduce a new interface XDesktop2 that implements the
> necessary interfaces, and a new service Desktop2 that acts as a service
> for XDesktop2.
> Then I make the XDesktop2 forward to the old Desktop code for the time
> being.
>
> Does this sound reasonable?

I wouldn't introduce the extra noise of an additional Desktop2 service. 
  While technically it would be an incompatibility to change the 
existing, old-style Desktop service (implementing multiple interfaces) 
into a new-style one implementing a single new XDesktop2, practically it 
should have little consequences.  (As old-style service definitions are, 
after all, little more than "glorious documentation."  I hope I don't 
miss any obvious blocker here.  Anyway, one would need to try this out 
to be sure.)

That leaves the question whether it would be considered a good idea to 
introduce XDesktop2 now that inherits exactly the same interfaces that 
the old Desktop service implements.  (The underlying question is whether 
that exact set of interfaces is actually a good choice there, or happens 
to be a historic mistake that should be improved upon.)  But thinking 
about it, that approach might just be a good one:  We start to do 
changes incrementally now, based on status quo, improve them over time, 
and by the time of an all-incompatible LO 4 have something new (but 
already time-tested) and we can remove any stuff that has become 
obsolete (and potentially clean up the new stuff, like renaming 
XDesktop2 back to XDesktop or some such).

The only problem is with publishing:  Ideally, the new XDesktop2 should 
remain unpublished for now.  However, the existing (published) Desktop 
service could then not be rewritten to use XDesktop2.  Solutions would 
be to either:

A  Introduce a new Desktop2 after all.

B  Make XDesktop2 published.

C  Temporarily remove the codemaker check that prevents a published 
new-style service from using an unpublished interface.

I could envision going down route C.  What do others think, overall?

Stephan