[fdo-internals] Updated FDO RFC 23 For Review

[Traian Stanev]

In particular, I am interested in the answer, because all FDO interfaces derive from FdoIDisposable, which is most certainly not a pure virtual interface, so none of the FDO interfaces are pure virtual to begin with.

Traian



From: Traian Stanev
Sent: Friday, July 18, 2008 2:35 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] Updated FDO RFC 23 For Review


"I believe the managed API requires the interfaces to declare only pure virtual methods, so I don't think a default implementation can be used."

Does anyone know the reason for this? I'm just curious.

Traian



From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Ronnie Louie
Sent: Friday, July 18, 2008 2:31 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] Updated FDO RFC 23 For Review

Yes, NOOP methods will be implemented for all the providers that will not use the class names hint.    I believe the managed API requires the interfaces to declare only pure virtual methods, so I don't think a default implementation can be used.

From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Steve Dang
Sent: Friday, July 18, 2008 12:24 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] Updated FDO RFC 23 For Review

By making Get/SetClassNames pure virtual, do you plan to implement NOOP methods for all non-RDBMS based providers? Is there any reason to not make these methods non-pure virtual with default NOOP implementation?

Thanks,
Steve.

From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Ronnie Louie
Sent: Friday, July 18, 2008 11:22 AM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] Updated FDO RFC 23 For Review

RFC 23 (http://trac.osgeo.org/fdo/wiki/FDORfc23) is updated once again to propose changes to DescribeSchema for allowing a hint for restricting the classes in the returned schema.  Completion of the review for the RFC is still targeted for July 23.  As usual, please reply to this list with your comments.

Thanks
Ronnie

From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Ronnie Louie
Sent: Thursday, July 17, 2008 5:47 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] Updated FDO RFC 23 For Review

Traian's suggestion offers a cleaner solution and keeps the API compact.  It's quite similar to the originally proposed DescribeSchema changes, but no errors or return values are used to indicate support for retrieving specific classes.  The command will just work, returning only the requested class definitions, or all of them depending on the provider's implementation.

If there are no objections, I will revise the RFC again with this solution.

thanks
Ronnie

From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Traian Stanev
Sent: Thursday, July 17, 2008 2:04 PM
To: 'FDO Internals Mail List'
Subject: RE: [fdo-internals] Updated FDO RFC 23 For Review


Yes, that was what I had in mind. The function call setting the filenames as hints would never error - in fact it can have a blank default implementation in FdoIDescribeSchema. This way, only providers which want to optimize based on the hint would overload that function and take into account that input. For all other providers, DescribeSchema would work as before, without any code changes at all - only a recompile of the provider would be needed.

Traian


From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Greg Boone
Sent: Thursday, July 17, 2008 2:59 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] Updated FDO RFC 23 For Review

I guess I am not totally against the idea of the class names being used as a Hint. As long as there is no exceptions thrown if a provider does not support the Hint or no return values need be evaluated.

Greg

From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Traian Stanev
Sent: Thursday, July 17, 2008 1:10 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] Updated FDO RFC 23 For Review


OK I see. In that case, I'd prefer the breaking change in DescribeSchema (where you can ask for specific classes). It's true that we have to update all providers, but IMO keeps the API more compact.

A crazy alternative would be to add a function to the DescribeSchema command which lets someone specify feature class names they are interested in. This can then be treated as a hint by the providers which need that and other providers can ignore it and return the full schema - either way the class that the caller cares about will be in the returned schema. This way there would be no work required of provides that don't need it, and there are no new commands or capabilities to add.

Traian


From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Brent Robinson
Sent: Thursday, July 17, 2008 12:58 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] Updated FDO RFC 23 For Review

Hi Traian,

It would be the last case. The RDBMS providers cache the schemas but the first time retrieval can be expensive when there are many classes.

Brent.

From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Traian Stanev
Sent: Thursday, July 17, 2008 12:53 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] Updated FDO RFC 23 For Review


The impact on non-RDBMS providers like SDF is a bit unclear to me. It seems like there are two cases.


(1)    FDO connection is kept open. In such case DescribeSchema operation is free, since the schema is cached internally by the connection.

(2)    FDO connection is opened and then those new commands are executed - in this case the schema would have to be deserialized, in its entirety, which would not make the new commands perform any faster than DescribeSchema.

It seems to me like making the RDBMS providers cache their schema internally is something that would make the extra commands unnecessary, and would only limit code changes to providers which do have a problem with DescribeSchema, instead of having either all providers implement new commands, or having client code have two code paths everywhere it deals with getting a schema. However, I do not know enough about the RDBMS providers to be sure if caching the schema is not possible in their case. Or are we talking about the case where getting the schema even once, to cache it, is too expensive (like if there are 1 million classes in Oracle)?


Traian



From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Jason Birch
Sent: Thursday, July 17, 2008 12:41 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] Updated FDO RFC 23 For Review

I like this approach, though for consistency it would be nice if all of the providers implemented these new commands as soon as possible.

>From my perspective, having to special case everything based on capabilities can get a bit frustrating, especially for lowly scripters who barely understand how to tie their shoes :)

Jason

From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Ronnie Louie
Sent: Thursday, July 17, 2008 00:39
To: FDO Internals Mail List
Subject: [fdo-internals] Updated FDO RFC 23 For Review

RFC 23 (http://trac.osgeo.org/fdo/wiki/FDORfc23) has been updated and re-posted for review.   In particular, the previously proposed changes to DescribeSchema have been dropped, and replaced with a new DescribeClasses command.  Also the API command names for enumerating schemas and classes have been updated to GetSchemaNames and GetClassNames.

Please review the new proposal and reply to this list by July 23.

Thanks
Ronnie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/fdo-internals/attachments/20080718/1cc824d3/attachment-0001.html