Menu
▾
▴
RE: update on DDS DynamicData
|
From: Malitsky, N. D <mal...@bn...> - 2010-09-29 15:03:54
|
Hi Greg, >. I'd only implement exchanging a "dynamic Any" Yes, it is one of many applications. In general, you can consider this dynamic container as a low-level generic interface/container of common frameworks, such EPICS servers, database and data stream management systems. As a result, its interface should be fast. For example, in the case of EPICS, it should directly provide access to original records without maintaining or creating the intermediate objects. Actually, here is one of principle differences between the current versions of PVData and DynamicData interfaces. >plus all their variations for arrays In my proposal, we need only two methods dealing with arrays. >I wouldn't implement the native type support (getFloat, getDouble, getwchar Again, probably we are talking about different use cases. But, in the case of the dynamic container, these methods allow to provide the direct and efficient access to data. You know, this approach is pretty common, for example: - CORBA Any: http://download.oracle.com/javase/1.4.2/docs/api/org/omg/CORBA/Any.html - JMS Map Message: http://download.oracle.com/javaee/1.4/api/javax/jms/MapMessage.html - Google C++ Message: // Singular field getters ------------------------------------------ // These get the value of a non-repeated field. They return the default // value for fields that aren't set. virtual int32 GetInt32 (const Message& message, const FieldDescriptor* field) const = 0; virtual int64 GetInt64 (const Message& message, const FieldDescriptor* field) const = 0; virtual uint32 GetUInt32(const Message& message, const FieldDescriptor* field) const = 0; virtual uint64 GetUInt64(const Message& message, const FieldDescriptor* field) const = 0; virtual float GetFloat (const Message& message, const FieldDescriptor* field) const = 0; virtual double GetDouble(const Message& message, const FieldDescriptor* field) const = 0; virtual bool GetBool (const Message& message, const FieldDescriptor* field) const = 0; virtual string GetString(const Message& message, const FieldDescriptor* field) const = 0; ... All previous technologies however provide some technology-specific interface. >From my point of view, the DDS Dynamic Data specification suggests the systematic approach with the optimal and well-defined scope: type system of the C programming language. Regards, Nikolay -----Original Message----- From: White, Greg [mailto:gr...@sl...] Sent: Tuesday, September 28, 2010 9:17 PM To: Malitsky, Nikolay D; epi...@li... Subject: Re: update on DDS DynamicData Hi Nikolay, Sure, I can provide a slide for the AIDA approach as it is now. Like I said in the meeting though, there are two things I'd bear in mind the next time: 1) If the protocol was exclusively for services (as AIDA was intended to be), as opposed to for control data plus services, then I wouldn't implement the native type support (getFloat, getDouble, getwchar etc, etc, etc, plus all their variations for arrays). It's these little native getters and setters that I was referring to in my email by making the protocol too "wide". The number of methods in the data exchange API was just too many (10 basic types x 2 for arrays, x 2 for getting and setting = 40! It's just too many). I'd only implement exchanging a "dynamic Any" - an object whose definition/type you define at runtime, but whose interpretation is invariant by service. That is, if the client has requested Archive data, and given an option that they would like the data in the for of values and datestamps with repeat counts, then they know they will get exactly 3 arrays back, float[] of values, string[] of datestamps, int[] of repeat counts. That is, it would work exactly as web services work that transport an XMLHttpRequest Object over HTTP. 2) I'd get drunk more Greg On Sep 28, 2010, at 6:23 AM, Malitsky, Nikolay D wrote: > Hi Greg, > >> In particular your slides 4- onwards map 100% to AIDA's existing > interface, which wrapped CORBA. > > Great. Actually, it is important because this interface is designed via > several iterations > as a trade-off among different use cases. Now I am working on slides for > PCaPAC'10 about > the high-level application protocols and interfaces (such as CDEV, > CORBA, DDS Dynamic Data, > Google's Protocol Buffers, PVData, ...) and would be glad to add your > slide with the AIDA > approach. > >> A couple of questions. > > In short, this specification is about dynamic containers (like cdevData, > CORBA Any, > Google's Dynamic Message, EPICS PVData). It is already available as a > beta > version (http://www.omg.org/spec/DDS-XTypes/1.0/Beta1/) and will be > formally > released in April 2011. > >> but just too wide an interface for a service layer. > > As you can see, Dynamic Data is not an interface for a service layer > (like cdevDevice), > but it is a generic interface to different data types (like cdevData). > >> Were they the 2 things on slide 3? > > Yes. Actually we discussed about many topics. They also agreed that this > specification > is more generic than DDS and the reference implementation should be > DDS-independent. > > Regards, > Nikolay > > > > -----Original Message----- > From: White, Greg [mailto:gr...@sl...] > Sent: Monday, September 27, 2010 11:23 PM > To: Malitsky, Nikolay D > Cc: epi...@li... > Subject: Re: update on DDS DynamicData > > Hi Nikolay, looks cool. Bizarrely, the interface to the DDS you describe > looks functionally absolutely identical to the existing interface of the > AIDA system I wrote for SLAC. In particular your slides 4- onwards map > 100% to AIDA's existing interface, which wrapped CORBA. > > A couple of questions. > I take it DDS is something that now exists in Java 5. If so, what's the > relationship of your email to your powerpoint? Specifically, what is it > that your meeting with OMG was intended to get them to do or adopt? Were > they the 2 things on slide 3? If so, then sure, I'm all for those. In > fact in AIDA we also implemented like 30 interface methods for getting > and setting primitive types and arrays of primitive types. That's fast > (<2ms), but just too wide an interface for a service layer. > > Cheers > Greg > > On Sep 26, 2010, at 2:00 PM, Malitsky, Nikolay D wrote: > >> <DynamicDataProposal-2.ppt> > |