Refactor the code to compile without ArchiCAD

[nickger]

I thought ArchiCAD connector and generic API are separated, but they are not. SpecleLib contains a lot of code which relies on ArchiCAD and serves for connector's interface. It is very difficukt to understand what to exclude to make it just work.

[r-wessel]

The connector serves as a conduit between some graphics/BIM host and a speckle server, i.e. it isn't a stand-alone application. The vast majority of the code in SpeckleLib is generic C++ with no dependencies on any specific host, but areas dependent on unique host behaviours are currently implemented for Archicad and couched in #ifdef ARCHICAD to allow other implementations to be added as required.

For example, BIMElementDatabase is an abstract interface for the primary object database of the host application. Every host will have a different engine and objects. An implementation for Archicad is provided in ArchicadElementDBaseEngine andArchicadDBaseCore (because Archicad was the first target), but any number of additional implementations for different hosts can be added and specified as the ElementDatabaseEngine in BIMElementDatabase, e.g.:

	///Define other platform engines here as required
#ifdef ARCHICAD
	using ElementDatabaseEngine = ArchicadElementDBaseEngine;
#endif
#ifdef VECTORWORKS
	using ElementDatabaseEngine = VectorworksElementDBaseEngine;
#endif

If the ARCHICAD macro is undefined, ArchicadElementDBaseEngine will simply be ignored by the compiler.

Other host implementations would not have to use the object types linked to Archicad either, e.g. an implementation for Solidworks might only require Parts and Assemblies (and could completely ignore BIM elements like Wall, Roof etc.).

The intention is to allow SpeckleLib to abstract the concept of an application API - they essentially have the same ingredients but with different implementations. For example, most C/C++ APIs (unfortunately) have a unique string implementation, e.g. Archicad has GS::UniString, GS::String, uchar_t, IO::Name etc. SpeckleLib declares a speckle::String class that simply defines adapters to the native implementation so a single speckle::String type can be used universally in SpeckleLib (and still work harmoniously with the native API string type, including std::string). If Vectorworks was implemented (for example) an equivalent adapter could be added for TXString (the Vectorworks string type) couched in '#ifdef VECTORWORKS', e.g.:

#ifdef ARCHICAD
		/*!
		 Constructor
		 @param string An Archicad string
		 @param howMany The number of chars to copy (nullopt for full length)
		 */
		String(const GS::UniString& string, sizeOption howMany = std::nullopt) :
				String{reinterpret_cast<const char16_t*>(string.ToUStr().operator const unsigned short *()), howMany} {}
#endif
#ifdef VECTORWORKS
		/*!
		 Constructor
		 @param string A vectorworks string
		 @param howMany The number of chars to copy (nullopt for full length)
		 */
		String(const TXString& string, sizeOption howMany = std::nullopt) : String{string.GetStdString(), howMany} {}
#endif

The net result is that the code for SpeckleConnector can be almost entirely generic (for any target) because the host differences are absorbed within SpeckleLib, meaning that any improvements or changes at this level will automatically be inherited by all hosts implemented within SpeckleLib. The only component lacking abstraction at this level is a generic implementation of a palette (modeless dialog), but this can be added in future.

Implementing an additional platform might only require additions to about 5-10% of the SpeckleLib code base (depending on the range of objects supported by the host). For example, implementation of the JS CEF portal (or equivalent) only requires host-specific code for:

• Installing/defining the supported JS objects
• Executing arbitrary JS code
• Executing a bridge method in the hosts primary event loop (or equivalent)
• Declaring the serialisation protocol for data exchanged with JS (Archicad uses the binary serialisationJS::Base where others might simply use JSON)

This might only require an additional 50 lines of code to allow all the browser bridge functionality to be inherited by a different host application. This could have been avoided if C++ applications relied on common software components, but unfortunately almost everything in 3D/BIM engine APIs is uniquely implemented (even for something as ordinary as strings).

[nickger]

Thank you for the response, but basicaly, I asked this question because it doesn't work that simple... There are numerous places in the code without ARCHICAD decorator but they require Archicad API.
My current task is even easier: I want to connect to a transport (local SQL or Speckle Server) and process data in a manner similar to .net API. No connector to the software is required. Where should I start from?

[r-wessel]

Yes, there are probably cases where references to Archicad have not been enclosed in

#ifdef ARCHICAD
...
#endif

Only Archicad has been implemented so far (and we've only just reached the beta period) so you are the first to explore other platforms with this code base. Cases where the Archicad API are not blocked out (for other platforms) are fundamentally bugs - If you have time, please flag any points where we've missed this and it can be addressed.

There may be other cases where we need to allow SpeckleLib to entirely ignore certain interfaces, e.g. in your case BrowserBridge is probably irrelevant. We could allow parts of the library to be optionally compiled or ignored with macros, e.g. IS_BROWSER_BRIDGE_REQUIRED, sparing the need to implement code that isn't required. This is something that will be learned over time as use cases are established.

All Speckle server interaction is currently delegated to the JS interface, e.g. sending a model to a Speckle server, so no code for interacting directly with a Speckle server has been implemented in SpeckleLib (yet). I expect this will follow in time - the C++ code base is still in its infancy (whereas the C# base has years of development in it).