Disposition: ?
OMG Issue No: ?
Title: CadConnection, CadSystem: Avaliable_models() enhancement
Source:
Markus Helmke, Produktionstechnisches Zentrum (PTZ)
Technische Universität Berlin
Email: markus.helmke@ipk.fhg.de

Summary:

The method "available_models()" provides access to models available to the active CAD System and returns all available models in a list. Up to now the method does not take into account how the models are structured on the server side. When a user selects a model it would be helpful to navigate through the tree structure of the servers file system. A similar problem is the specification of a users file name in that moment when he wants to use "save_model_as()" or "create_model()".
The proposed methods, data structures and definitions aim to improve navigation capabilities for both systems and users when accessing models. For various reasons a native CAD-system normally is able to access different directories which are presented also to the user. This is to let him structure his work but also in order to offer templates that ease the design process, because in most cases designer aren't starting from scratch, but they are provided with templates that cover predefined parameters or a special design philosophy.
Assuming a user wants to store, create, or open a model on the (maybe remote) machine running the Cad-Services he expects something like a "FileChooser"-dialog. The method "available_models()" was not designed to support such functionality and therefore needs to be extended.
The proposed methods allow for implementing the intended functionality because they represent an essential subset of methods needed to do the following:

• Navigation (get_root_directories(), get_models_and_folders(), get_parent_directory())
• Create new subfolder (create_new_folder())
• Providing information to choose a file or folder on the client side (get_models_and_folders())
  The concept provides the possibility not to expose the whole file system to the user by using "root_directories". Every directory can serve as root directory and thus only its subdirectories are exposed to the user. The user starts navigation in the one of the roots.
  The methods were taken from JAVA's abstract class "javax.swing.filechooser.FileSystemView" which serves as "JFileChooser's gateway to the file system" and as such promise to be sufficient. Additionally IWF has implemented against the proposed CAD-Services enhancement with success.

Resolution:
?

Revised Text:
The following typedefs, struct and operations are added to the CadConnection module respectively to the CadSystem interface:

module CadConnection
{

struct Path

;

typedef sequence<string> RootsList;
typedef sequence<Path> PathList;

interface CadSystem

;
};

Disposition: ?
Disposition Parameter: ?

see below

Suggest altering the input parameter CadFeature::ParameterSeq model_params on CadConnection::CadSystem to a CosPropertyService::Properties

This issue was previously (v 1.1) resolved

I suggest altering the use of EntitySeqs to LongSeqs - essentially to use Unique IDs as identifiers. [In places like: Model::delete_entity(), EntityGroup::add_entities(), EntityGroup::remove_entities()] I see there 2 main problems: 1. I don't see that it is really neccesssary to use the (in this case Entity objects) CORBA objects to identify an object. unique_id's could always be used. -> Less traffic and a lot easier to map. Besides: how much sense does the UidUnsupported exception make? unique ids can always be created. 2. The required mapping especially on the server side is somewhat tricky and not the fastest. You would have to map the CORBA objects to the implementation objects. Nasty thing to do.

see below

'CadMain::ModelInstance::component()' collides with the new 'component' keyword for IDL from CCM.

I suggest ro rename it to 'CadMain::ModelInstance::component_model()'.

see below

is there any reason, why the double parameter (tolerance) of CadGeometry::Curve::tessellate() is declared as an in parameter and not inout? In other places like CadGeometry::Surface::nurbs_representation() the tolerance parameter is declared inout.

see below

There are some different tessellation structures for different kind of entities (geometric and topologic) and some are for both (e.g. EdgeTessellationStruct). Three of the four structs have a obj_ref member with type Object.

Issues: 1. The type Object for obj_ref is too generic. 2. Some of the tessellation structs are for the use with one single interface (ConnectedFaceTessellationStruct -> Body) while some others are used in more than one interface (EdgeTessellationStruct -> Edge, Curve). 3. In some cases the obj_ref member of a single tessellation struct references a geometric entity (Curve, Surface), in others a topologic entity (Edge, Face, Body)

Proposed Solution: For each interface which provides tessellation (has a tessellate() method) there should be one corresponding tessellation struct with a obj_ref member of the type of the interface which generated the struct.

Edge -> EdgeTessellationStruct Face -> FaceTessellationStruct Curve -> CurveTessellationStruct Surface -> SurfaceTessellationStruct Body -> ConnectedFaceTessellationStruct

It would be much clearer that way and the redundancies pretty few.

The CadBrep::OrientedEdge interface has two very similar methods to get the Face/OrientedFace which uses the OrientedEdge. That's pretty redundant. Besides: Both methods deliver useful information only when the OrientedEdge belongs to one and only one Face. Otherwise an exception is generated. I don't really see the usefulness of those two method, especially since for many cases there are two Faces for the Edge and one can always traverse there via the EdgeLoop.

In the CadBrep module there are almost always two ways to traverse the topology: from the top level entities like Body to the underlying entites like Shell, Face, Edge, ... and the other way. For example I can get from Face to the OrientedFace which aggregates the Face or I can ask the OrientedShell in which Body it is contained. This does not make much sense to me. I always thought the topology is more or less hierarchical with Body is composed of OrientedShells which has reference to Shell and so on.
Unless I am missing something important, it is just some not so small overhead to have all those relations at hand and being uptodate with them. I would place such things in a client for I see it as application specific, if it is neccessary or not.

2. The Documentation for CadMain::Model::unique_entities() and CadMain::Model::top_level_entities() says the only valid types asked for are geometric entity types but there is only mention and used CadFoundation::Entity (in the doc and in the return types). If this should really be only geometric entities, the return types could be CadBrep::BrepEntity and the documentation should be much clearer on what is allowd and what a invalid type.

CADServices 1.1
1. In The CadMain::Model interface there is no clear way to get the DesignFeatures of a Model. The only possible way would be via top_level_entities() or unique_entities(), but these calls are for geometric entities (so it is written in the documentation).
Proposed Solution: add a call "CadFeature::DesignFeatureSeq design_features()" to CadMain::Model. The DesignFeatures should be more clearly seperated from the BrepEntities as they are to different sights on the same data and should not be mixed per chance.

I have a problem understanding how to interpret the
> vertex_number's for
> the points in CadGeometry::EdgeTessellationStuct. I don't see
> the need
> for a indexing here. It is just sequencial. Are there people,
> who want
> to do this another way?

In the PDF document (03-02-02) for the CadServices the return value for CadFoundation::Entity::reference_position is CadUtility::PointStruct, but in the idl files it is CadUtility::PointStructSeq.
I couldn't verify it against the newest documents (maybe newer than mine), because they were unreachable.
Besides, the description of this method is not very helpful (at least to me). I have no clue how to interpret it.

after changing the fourth parameter of CadConnection::CadSystem::create_model from CadFeature::ParameterSeq to CosPropertySevice::Properties recently, the exception CadConnection::BadParameter does not match the method anymore.
It should either be changed in a similar manner or kicked out completely (it is only used by create_model).

The method CadMain::Model::unique_ids_to_entities() can throw the CadMain::NotValidCadType exception but unlike the other methods able to throw this does not get TypeCodes as input. If the exception is there by accident I suggest it be removed.

In the PDF document for CADServices 1.1 (03-02-02) the description for CadMain::Model::unique_ids_to_entities() is missing

Where can one get the CadFeature::Parameter instances from to use in CadSystem::create_model() ?
As far as I know, the instance of a idl interface can only be created on the server (in a get method or in a factory) and I can see no way of creating empty CadFeature::Parameter instances.
Besides, why was CadFeature::ParameterSeq used on Model level (CadMain::Model::create_model(), CadMain::Model::get_parameter_set()) and not as in other places CosProperyService::Properties? It is not clear to me, what information is supposed to be behind these parameters.

This looks like a valid concern. We can fix this by using either CosProperyService::Properties in place of the CadFeature::ParameterSeq or we can created a CadFeature::ParameterFactory.

I suggest the use of Properties.