Unpublished interface to published service

Hi there,

I'm in the process of extending Calc's standard filter API
to cover new
types of filters.  In doing so, I will need to add a new
interface to an
existing UNO service (css.sheet.SheetFilterDescriptor), but
I'd like
this interface to stay unpublished until this API
stabilizes.

But I'm having trouble leaving the new interface
unpublished.  I've
added the following lines:

/** provides access to the collection of filter fields.
 */
[optional] interface
com::sun::star::sheet::XExtendedSheetFilterDescriptor;

but the building of offapi fails, noting that "you
can't use an
unpublished interface to a published service."  Is
there a way to get
around this?

Thanks,
Kohei



-- 
Kohei Yoshida - OpenOffice.org Engineer - Novell, Inc.
<kyoshidanovell.com>

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeudk.openoffice.org
For additional commands, e-mail: dev-helpudk.openoffice.org

Hi Kohei,

> But I'm having trouble leaving the new interface
unpublished.  I've
> added the following lines:
> 
> /** provides access to the collection of filter
fields.
>  */
> [optional] interface
> com::sun::star::sheet::XExtendedSheetFilterDescriptor;
> 
> but the building of offapi fails, noting that "you
can't use an
> unpublished interface to a published service."  Is
there a way to get
> around this?

I heartly disagree with Stephan's answer, but so far was not
able to
convince him (we already discussed this).

http://www.openoffice.org/issues/show_bug.cgi?id=69326
, btw, describes
the problem - please lobby for it .

In my opinion, the restriction that you cannot add
unpublished
interfaces as optional entity to published services is way
too strict.
There are very theoretic (sorry, Stephan) reasons for this,
but in
reality, all services which are affected by such a change
would not
suffer at all.

Mentionng the new interface in the document only is not a
valid
alternative, as this introduces an additional complexity in
the
generated IDL reference, is more easily overlooked by
readers, and can't
be examined at runtime (see
css.reflection.XServiceTypeDescription.getOptionalServices).


But, well, you asked for a workaround. I'll tell you one of
my best-kept
secrets , though it
will probably cease existing now that Stephan
knows about it: Just forward-declare the interface, instead
of including
the IDL, and pretend, in the forward-declaration, it is
published.

Ciao
Frank

-- 
- Frank Schönheit, Software Engineer        
frank.schoenheitsun.com -
- Sun Microsystems                      http://www.sun.com/star
office -
- OpenOffice.org Base                       http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - -

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeudk.openoffice.org
For additional commands, e-mail: dev-helpudk.openoffice.org

Frank Schönheit - Sun Microsystems Germany wrote:
> Hi Kohei,
> 
>> But I'm having trouble leaving the new interface
unpublished.  I've
>> added the following lines:
>>
>> /** provides access to the collection of filter
fields.
>>  */
>> [optional] interface
>>
com::sun::star::sheet::XExtendedSheetFilterDescriptor;
>>
>> but the building of offapi fails, noting that
"you can't use an
>> unpublished interface to a published service."
 Is there a way to get
>> around this?
> 
> I heartly disagree with Stephan's answer, but so far
was not able to
> convince him (we already discussed this).
> 
> http://www.openoffice.org/issues/show_bug.cgi?id=69326
, btw, describes
> the problem - please lobby for it .
> 
> In my opinion, the restriction that you cannot add
unpublished
> interfaces as optional entity to published services is
way too strict.
> There are very theoretic (sorry, Stephan) reasons for
this, but in
> reality, all services which are affected by such a
change would not
> suffer at all.
> 
> Mentionng the new interface in the document only is not
a valid
> alternative, as this introduces an additional
complexity in the
> generated IDL reference, is more easily overlooked by
readers, and can't
> be examined at runtime (see
>
css.reflection.XServiceTypeDescription.getOptionalServices).

> 
> But, well, you asked for a workaround. I'll tell you
one of my best-kept
> secrets , though it
will probably cease existing now that Stephan
> knows about it: Just forward-declare the interface,
instead of including
> the IDL, and pretend, in the forward-declaration, it is
published.

mmh, that is of course a bad hack. If we would extend
regcompare to 
detect this as well the build would fail again. I don't like
this 
approach. Either we find an agreement that it is allowed or
we shouldn't 
do it. So please don't do it this way at the moment.

Juergen

> 
> Ciao
> Frank
> 

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeudk.openoffice.org
For additional commands, e-mail: dev-helpudk.openoffice.org

Kohei Yoshida wrote:

> Hi there,
> 
> I'm in the process of extending Calc's standard filter
API to cover new
> types of filters.  In doing so, I will need to add a
new interface to an
> existing UNO service (css.sheet.SheetFilterDescriptor),
but I'd like
> this interface to stay unpublished until this API
stabilizes.
> 
> But I'm having trouble leaving the new interface
unpublished.  I've
> added the following lines:
> 
> /** provides access to the collection of filter
fields.
>  */
> [optional] interface
> com::sun::star::sheet::XExtendedSheetFilterDescriptor;
> 
> but the building of offapi fails, noting that "you
can't use an
> unpublished interface to a published service."  Is
there a way to get
> around this?
The only way would be to make the service itself
"unpublished" what of
course is not allowed also. Perhaps we could allow it for
this service
as it is an "old style service" and these services
never have been used
for anything else than documentation. So making it
"unpublished" won't
break any code. But I assume that this would create some
hassle.

Alternatively you could remove your new interface from the
IDL file
again (as I said: old style services are documentation only)
or you can
design a new, unpublished service and deprecate the old one.
This would
be a good opportunity to make this service a "new
style" one. 

Ciao,
Mathias

-- 
Mathias Bauer (mba) - Project Lead OpenOffice.org Writer
OpenOffice.org Engineering at Sun: http://blogs.sun.com/Gu
llFOSS
Please don't reply to "nospamformbagmx.de".
I use it for the OOo lists and only rarely read other mails
sent to it.

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeudk.openoffice.org
For additional commands, e-mail: dev-helpudk.openoffice.org

Hi Mathias,

> The only way would be to make the service itself
"unpublished" what of
> course is not allowed also. Perhaps we could allow it
for this service
> as it is an "old style service" and these
services never have been used
> for anything else than documentation. So making it
"unpublished" won't
> break any code. But I assume that this would create
some hassle.
> 
> Alternatively you could remove your new interface from
the IDL file
> again (as I said: old style services are documentation
only) or you can
> design a new, unpublished service and deprecate the old
one. This would
> be a good opportunity to make this service a "new
style" one. 

Sorry, but as even the inventors of new style-services say,
they aren't
the final solution to every problem, and they cannot be
applied to each
and everything. So, what you suggest is not a viable option,
as there
are enough old-style services around which cannot be
reasonably
converted to new-style ones.

We need a working solution for this. Currently, it are
hassles like
those which alienate even the good-will developers which
actually *do*
try to write good API documentation (it are way too few). If
we're
serious about our API, we shouldn't impose such artificial
restrictions
on ourselves.

Ciao
Frank

-- 
- Frank Schönheit, Software Engineer        
frank.schoenheitsun.com -
- Sun Microsystems                      http://www.sun.com/star
office -
- OpenOffice.org Base                       http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - -

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeudk.openoffice.org
For additional commands, e-mail: dev-helpudk.openoffice.org

Hi Juergen,

>> But, well, you asked for a workaround. I'll tell
you one of my best-kept
>> secrets , though it
will probably cease existing now that Stephan
>> knows about it: Just forward-declare the interface,
instead of including
>> the IDL, and pretend, in the forward-declaration,
it is published.
> 
> mmh, that is of course a bad hack. If we would extend
regcompare to 
> detect this as well the build would fail again.

Well, your comment in the mentioned issue reads
"accepted", so I thought
that my small, little, innocent hack  just
anticipates your resolving
of the issue 

Ciao
Frank

-- 
- Frank Schönheit, Software Engineer        
frank.schoenheitsun.com -
- Sun Microsystems                      http://www.sun.com/star
office -
- OpenOffice.org Base                       http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - -

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeudk.openoffice.org
For additional commands, e-mail: dev-helpudk.openoffice.org

Frank Schönheit - Sun Microsystems Germany schrieb:

> Hi Mathias,
> 
>> The only way would be to make the service itself
"unpublished" what of
>> course is not allowed also. Perhaps we could allow
it for this service
>> as it is an "old style service" and these
services never have been used
>> for anything else than documentation. So making it
"unpublished" won't
>> break any code. But I assume that this would create
some hassle.
>> 
>> Alternatively you could remove your new interface
from the IDL file
>> again (as I said: old style services are
documentation only) or you can
>> design a new, unpublished service and deprecate the
old one. This would
>> be a good opportunity to make this service a
"new style" one. 
> 
> Sorry, but as even the inventors of new style-services
say, they aren't
> the final solution to every problem, and they cannot be
applied to each
> and everything. So, what you suggest is not a viable
option, as there
> are enough old-style services around which cannot be
reasonably
> converted to new-style ones.

What in "this would be a good opportunity to make this
service a "new
style one" makes you believe that I proposed this as
the *solution* of
the problem? For me it's just a *side effect* of the
replacement of the
old service by a new one. So *if* a new service needs to be
changed for
whatever reason it *should* be considered to also make it a
"new style"
service. You see the difference?

I just asked for checking *if* a new service that should
replace or
complement an old one also could be a "new style"
service. Alternatively
the new service derived from the old (and "old
style") service could
also be extended and converted to a multiple inheritance
interface as
IMHO this is the better alternative and covers everything
you can get
from an "old style" service except the service
name.

I don't see any "old style" service that can't be
converted to a
multiple inheritance interface. In case it still should be
made
available as a service so that it can be instantiated by a
service
provider it can also become a "new style" service.
In case you still
need an "old style" service (for what?) it also
can be based on the
multiple inheritance interface.

Ciao,
Mathias

-- 
Mathias Bauer (mba) - Project Lead OpenOffice.org Writer
OpenOffice.org Engineering at Sun: http://blogs.sun.com/Gu
llFOSS
Please don't reply to "nospamformbagmx.de".
I use it for the OOo lists and only rarely read other mails
sent to it.

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeudk.openoffice.org
For additional commands, e-mail: dev-helpudk.openoffice.org

Hi Mathias,

> What in "this would be a good opportunity to make
this service a "new
> style one" makes you believe that I proposed this
as the *solution* of
> the problem?

Perhaps the fact we talked about a *problem*? 
Sorry, seems I didn't get you right then.

> I just asked for checking *if* a new service that
should replace or
> complement an old one also could be a "new
style" service.

In all cases which I encountered so far, it wasn't about a
new service,
but about extending an old one with additional information,
so I'm
unsure to which extent we talk past each other here.

> I don't see any "old style" service that
can't be converted to a
> multiple inheritance interface.

Beforehand: I'm a strong friend of multiple inheritance
(MI), and always
strive to use it where possible, when defining new API.
Finally, it has
some cool advantages when using this API, though some
disadvantages when
implementing it, but this is a one-time pain only.
(There are a few of our old-style services which I'd really
*love* to
convert ...)

However, there are a few downsides ... or facets which make
it easier
for an implementor to create downsides ... or special
situations where
MI doesn't have any concrete advantage IMO ... but I don't
really want
to open this Pandora's box now and here , finally,
the original topic
is another one which I'm more interested in right now.

Ciao
Frank


-- 
Frank Schönheit                        
StarOffice/OpenOffice.org Base
frank.schoenheitsun.com                    +49 40 23 646
663 / +66663
Sun Microsystems Germany                         Hamburg,
Nagelsweg 55
------------------------------------------------------------
----------

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeudk.openoffice.org
For additional commands, e-mail: dev-helpudk.openoffice.org

Frank Schönheit - Sun Microsystems Germany wrote:
> Hi Juergen,
> 
>>> But, well, you asked for a workaround. I'll
tell you one of my best-kept
>>> secrets , though it
will probably cease existing now that Stephan
>>> knows about it: Just forward-declare the
interface, instead of including
>>> the IDL, and pretend, in the
forward-declaration, it is published.
>> mmh, that is of course a bad hack. If we would
extend regcompare to 
>> detect this as well the build would fail again.
> 
> Well, your comment in the mentioned issue reads
"accepted", so I thought
> that my small, little, innocent hack  just
anticipates your resolving
> of the issue 

"accepted" means that the task is correct for me
and that i will take 
care of it. But it means not that i 100% agree so far, i am
somewhat 
undecided 

Juergen

> 
> Ciao
> Frank
> 

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeudk.openoffice.org
For additional commands, e-mail: dev-helpudk.openoffice.org

On Mon, 2007-07-23 at 12:43 +0200, Juergen Schmidt wrote:
> Frank Schönheit - Sun Microsystems Germany wrote:

> > Well, your comment in the mentioned issue reads
"accepted", so I thought
> > that my small, little, innocent hack  just
anticipates your resolving
> > of the issue 
> 
> "accepted" means that the task is correct for
me and that i will take 
> care of it. But it means not that i 100% agree so far,
i am somewhat 
> undecided 

Well, either way, please keep us informed of the progress of
the
discussion.  I'm personally with Frank on this issue; I
think it's a
perfectly sound compromise to allow unpublished interface to
a published
service, at least two developers see the need for it . 

Kohei

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeudk.openoffice.org
For additional commands, e-mail: dev-helpudk.openoffice.org