Page 1 of 1

Maintaining and sharing TextPipe filters in the world of Git ?

Posted: Fri Jan 11, 2019 2:29 am
by DFH
Hi Simon,

With TextPipe filters being stored in a binary format (.fll) this makes maintaining and sharing filters less than convenient in the world of Git based services and software providers such as GitHub, GitLab and BitBucket.

Yes - one can Export a filter in various ways - but this is an extra complication and one that would not be a smooth process for many users.
And there's no Import option to load a filter seamlessly from any of the Export formats.

You have intimated that your long term goal would be store filters in XML.

If XML was then the format that user can upload to a Git based repository, then revision control and collaboration would be become feasible.
This would only work if this became one of the native file formats that TextPipe can Open and Save filters as.

Questions
1. Does your XML design philosophy match these requirements?
2. Where are you up to in the path towards using XML?

Best regards,

David

Re: Maintaining and sharing TextPipe filters in the world of Git ?

Posted: Tue Feb 05, 2019 10:22 pm
by DFH
Hi Simon,

I'm still waiting for a response to this important topic.

Best regards,

David

Re: Maintaining and sharing TextPipe filters in the world of Git ?

Posted: Thu Mar 14, 2019 1:29 pm
by DataMystic Support
Thanks David,

I like the idea, and also the collaboration that this could bring to bear.

XML is still not on the table yet, but we are definitely making moves to uplift the TextPipe ribbon UI, various copybook extensions and a range of other features. XML is still on the list.

Regards,

Simon

Re: Maintaining and sharing TextPipe filters in the world of Git ?

Posted: Wed Mar 20, 2019 6:56 am
by DFH
Hi Simon,

What do you have in mind as to "uplift the TextPipe ribbon UI" ?

David

Re: Maintaining and sharing TextPipe filters in the world of Git ?

Posted: Wed Mar 20, 2019 8:05 am
by DataMystic Support
Making it Windows-native, and work smoothly. The current Delphi control we use is very buggy and has required lots of kludgy workarounds