Hi all,

well that was quick ... I just had another deep-dive in Apache Thrift ... guess 
I was right: Seems Thrift is very similar to Protobuf as it helps define a 
model and have model, parsers and serializers generated from that. It looks as 
if it supports more transport protocols, but doesn't offer direct ways to 
provide custom protocols. 

My gut feeling tells me DFDL seems to be the best match for our needs, but also 
seems to be the option with a non-existing full tool stack :-(

Chris



Am 09.01.19, 15:06 schrieb "Christofer Dutz" <[email protected]>:

    Hi all,
    
    Ok ... so protobuf seems to be semi-ideal ...
    
    It seems that you can use it to model the structure of data. Protobuf is 
good for generating model classes, parsers and serializers for a given model 
... the binary data-format is a result of this. 
    
    We want the opposite: We want to generate a model from a known output 
data-format. In general this could be somehow achieved with protobuf, however 
it is very difficult to produce the definition in a way that it is able to 
parse a given data format. 
    For example simply outputting one byte seems to be problematic. I was able 
to somehow hack an enum and provide some extension to allow providing code 
values, but we don't have the level of control we would need to and the result 
is not very readable.
    I was able to quite easily setup the maven build to generate java code for 
parsing and serializing a model ... so that was good.
    
    DFDL looks as if it's ideal for describing the data format, however I 
couldn't find tooling to generate model, parser and serializer from a DFDL 
definition. I subscribed to our brother incubating project Daffodil and asked 
on their list ... perhaps I have to get my hands dirty and implement the maven 
plugin and code generators as part of that project ... I am hoping not having 
to do that. 
    
    I'll check out Thrift in parallel  ;-)
    
    
    Chris
    
    
    
    Am 09.01.19, 11:19 schrieb "Christofer Dutz" <[email protected]>:
    
        From my first look at thrift some time ago, that's more about API and 
not about the actual payload, is it?
        
        How about I try to do a protobuf version of the "s7-protocol" and you 
give thrift a try? Another option would be the DFDL option.
        
        Chris
        
        Am 09.01.19, 11:13 schrieb "Julian Feinauer" 
<[email protected]>:
        
            Hi Chris,
            
            we worked (and work) with Thrift [1] at several places.
            Thrift is a strong contender to protobuf and both have their 
specific advantages and disadvantages.
            Perhaps I would prefer Thrift as it comes from the Apache Ecosystm 
(and supports more langauges) but generally, Tim can say more about working 
with Thrift.
            
            Best
            Julian
            
            [1] https://thrift.apache.org/
            
            Am 09.01.19, 10:45 schrieb "Christofer Dutz" 
<[email protected]>:
            
                Hi all,
                
                while I’m currently working on refactoring the S7 driver to a 
simpler structure so we can convert it to other languages more easily. A 
colleague of mine pointed me to protobuf/protocol buffers from google [1]
                From a quick look at it, it does seem as if it could suit our 
needs quite nicely. I would like to try out if it’s possible to model the S7 
data structures in this way. If it works we could eventually quickly create 
something that serializes/deserializes given data in any language …
                
                It seems to be a lot simpler than the DFDL [2] I was thinking 
of, so guess we have to find out if it has all the capabilities we need.
                
                Any thoughts?
                
                Chris
                
                
                
                
                [1] 
https://developers.google.com/protocol-buffers/docs/javatutorial
                [2] 
https://en.wikipedia.org/wiki/Data_Format_Description_Language
                
                
            
            
        
        
    
    

Reply via email to