libredwg
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [libredwg] LibreDWG architectural changes


From: Felipe Castro
Subject: Re: [libredwg] LibreDWG architectural changes
Date: Tue, 9 Dec 2014 09:20:48 -0200

Hi Gagan,


2014-12-08 13:20 GMT-02:00 gagan <address@hidden>:

LibreDWG reads file and stores that into memory. When this data is read by some CAD software, it is then again allocated into CAD program's document memory. This basically is a wastage of memory or can be said as we are keeping same data at two places.

It was also pointed by Rallaz ( a developer of LibreCAD and also developed LibDXFrw ).

I think we should change the library so as to directly send data to library functions instead of first storing it in memory and then accessing and keeping it in seperate memory location.


I just thought of simplicity for the developer to use the library with the current approach. I don't like much the idea to put functions as arguments to other functions, for me it's a pain when a library presents this method. Well, just a personal taste of mine.
 

Looking over python support, I think we should deprecate the old swig link and find some better way for binding to python. The new API also needs python bindings too.


Completely agree. And also, I think any language binding should come only after a minimal stable base API. Why worry about this, if even the basic doesn't work well yet?
 

Also thinking to totally remove the write support. What say ?


That would be nice too, and one of the reasons I think LibreDWG stucks. Read support is something very good and already much complicated. Why not dominate it first, and only then worry about writing capability? The work for this library is something huge, if there is not a step-by-step "humble" planning, it will reach nowhere.

 

Further I want to ask is it necessary to remaim in C ? Can't we move towards C++ ? IIRC the GNU coding standards have changed and its not necassary to use C anymore( please correct me if wrong).


Another taste of mine, I don't like the "complications" imposed by that "++". But feel free to do what be necessary, if the community likes it, so...



reply via email to

[Prev in Thread] Current Thread [Next in Thread]