#1 Re: Feature Requests » Querying module properties without loading the module » 2014-12-22 17:20:02

How would ResolverHooks be used to address the following situation?

Assume a client wants to access module property values to be used as data, and those values are to come only from certain modules based on other module property values. In addition, the client would like to do this without loading those modules.

#2 Re: Feature Requests » Querying module properties without loading the module » 2014-12-16 15:17:54

Having a module’s properties accessible without loading the module, allows a client to access data with little computational overhead. Of course, this could be accomplished through the embedded resource feature provided by C++ Micro Services. However, the name-value pair interface provided by the concept of module properties makes accessing date more convenient and amenable to other property related features such as filtering.

Two possible uses are data only modules and determining if a module should be loaded. The ReqCap model addresses the latter. Capabilities are simply properties and requirements are simply filters on those properties. Of course, the ReqCap model may layer on additional semantic behaviors, but underneath it’s simply employing properties and filters. Bottom-line, it’s great to use the ReqCap model to stay consistent with OSGi, but it’s also nice to expose the underlying module properties and filtering of those properties for other uses.

#3 Re: Feature Requests » Querying module properties without loading the module » 2014-12-15 15:10:49

A useful feature related to this one would be filtering auto-loaded modules based on module properties; as well as, location. Either the client code or the framework will need to do this filtering. Better it be implemented once within the framework than differently by every client. What do you think?

#4 Re: Feature Requests » Querying module properties without loading the module » 2014-12-08 15:00:35

I'm eager to use this new installed state. When will 3.0 be available with this feature?

#7 Re: General Discussions & Feedback » Building service/client modules with different, incompatible compilers » 2014-10-08 13:31:39

The status quo is adequate for our current needs; however, having plugin compatibility across compilers offers unique opportunities.

Herb’s proposal looks quite promising, but as you point out, it’ll be many years before we see it in practice. In the meantime, John’s CppComponents demonstrates there are intermediate alternatives. My major concern about CppComponents is the overhead of runtime mediation across compiler interfaces. This is eliminated by Herb’s proposal. But as Herb points out his solution also has performance and flexibility costs. Thus he proposes C++ ABIs be specified rather than being the default. 

If CppMicroServices is to support cross-compiler plugins, it makes sense (as you point out) to have a mechanism to opt into this feature for performance and backward compatibility reasons. Although remote services could be used, it seems to be overkill for this purpose. Can you elaborate on how declarative services would be used to achieve this?

As you point out, CppComponents intrudes on the CppMicroServices service interface declaration. I believe this is because you’re both addressing the same problem, and it appears you’re both using the same design pattern. Which means there’s an opportunity to combine the two. However, such a blending would not be at a superficial level. You may wish to consider collaborating with John in this regard. He indicated a desire to implement a “package manager” (which you have) and you’d like cross-compiler plugins (which he has). Just a thought.

If CppMicroServices had cross-compiler plugin support that could be selectively “switched” on/off, then a light-weight verification mechanism to detect compiler version could be used to determine when to use this feature. Thus making this support transparent.

-Wayne

#9 Re: Feature Requests » Querying module properties without loading the module » 2014-09-08 18:31:55

I would think appending binary blobs should work on ARM and iOS as well. Are you aware of any issues in this regard?

#10 Re: Feature Requests » Querying module properties without loading the module » 2014-08-12 20:44:39

Please let me be clear. I'm in no way advocating for additional release 3.0 features. I'd like to see it as currently defined as soon as possible.

The requirements for my current project are quite modest, and release 2.1.1 is adequate. However, other projects coming on line will require release 3.0, and will (over time) generate a large number of plugins whose configurations will need to be managed. So our need for Config Admin is probably similar to yours. My fear is that without Declarative Services maintaining all those plugins due to framework changes will be a nightmare. I would think you’ll have the same problem.

#11 Re: Feature Requests » Querying module properties without loading the module » 2014-08-12 14:34:17

Much thanks for scheduling this feature for release 3.0. Is there a due date for this release?

Release 3.0 related topic:
The release notes for version 2.0 mentioned Config Admin and Declarative Services will be worked on first. However, they don't appear to be included in release 3.0. Both are quite useful in a production environment. Do you know when these features will be available?

#12 Re: Feature Requests » Querying module properties without loading the module » 2014-04-18 12:34:24

Excellent idea. I believe this would also allow for encryption of metadata for those who have security concerns. I’m eager to try this out. Please keep me posted.

#13 Re: Feature Requests » Querying module properties without loading the module » 2014-04-15 14:06:41

Generally I prefer your idea of appending module meta-data to the module’s shared library. As you point out, finding a suitable solution is not obvious. However, C++ Micro Services has one advantage over the typical use of embedded blobs. A module doesn't need to have direct access to its own metadata. A module can retrieve its properties from the framework that can cache them before loading the module.  That means you’re free to come up with a solution that doesn't use traditional schemes (e.g. global statics, linked data sections or embedded resources). Such a solution would also avoids the module needing to redundantly load its metadata and potential interference with the module’s own use of embedded resources and data.

A relatively naive approach is to simply append the blob in such a way that it doesn't interfere with the module’s binary format and cache at the end of the blob its offset from the start of the file. I know this is more easily said than done.

#14 Re: Feature Requests » Querying module properties without loading the module » 2014-04-09 15:52:06

I'm curious to know your thoughts about the two different implementations you mentioned. That is embedding meta-data into shared libraries in file readable form such as appending a zip file to the end of shared libraries, or a framework that’s built on top of shared libraries to add file readable meta-data. An example of the latter approach is the Poco OSP zip-based bundles. What you do see are the pros and cons of these two approaches, and why do you choose the former?

#15 Feature Requests » Querying module properties without loading the module » 2014-04-08 20:25:05

WayneBailey
Replies: 20

Please correct me if I’m wrong, but it appears that a module must be loaded to examine its properties. This would imply that modules need to be loaded to determine if you need them. If there are a large number of plugins, this could be a significant performance issue. Is there or will there be an efficient way to examine module properties without loading them? For example, on Windows a DLL’s embedded resources can be queried without loading the DLL.

Board footer

Powered by FluxBB