[cad-linux] Re: CAD with server/client architecture
- From: "Brian Johnson" <bjohnson@xxxxxxxxxxxx>
- To: cad-linux@xxxxxxxxxxxxx
- Date: Mon, 12 May 2003 20:29:35 +0000
I appreciate the excitment, but what db and what language is going to be used
Perhaps a review (even if only a quick one) of the databases available and the
creation of a desired feature list might be in order. MySQL seems to be the
most
popular and one of the fastest, but perhaps other desired features would dictate
another db. Natixe XML handling might be a good thing for instance. Also some
of
the more advanced commit and rollback transaction abilities might be beneficial.
Running on linux or windows or other OS a needed feature? Existing good db
management software available? replication?
Also, processing speed will be paramount for the main app. Is there anything
faster
than a C based system for that? Again, before we go too far, some consensus
should
be reached.
Eric Wilhelm (ewilhelm@xxxxxxxxxxxxx) wrote:
>
>
>> The following was supposedly scribed by
>> Jim Parker
>> on Monday 12 May 2003 02:42 pm:
>
>>Let me know if you want to take this discussion offline ... I am
>>tempted to send my data format to you to allow a more detailed
>>discussion of its merits.
>>
>I'm only a self-taught perl-hacker, so keep that in mind when throwing tech
>stuff at me. Not that I can't understand it, but I likely won't have time
>(especially in the coming weeks) to read through it all. I'd gladly review a
>summary (diagrams good, C bad :)
>
>>I decided to leave Color/Stipple/Size information in the entity
>>structs. I decided the computational overhead of looking
>>searching/sorting the additional lists are not worth it. However, it
>>should be noted that they are seperated out from the geometry data in
>>the SQL database. So it should be trivial to extract just geometry
>>data for any module that may need it.
>>
>This sounds good. The program would need the speed-optimized structs, but if
>you can draw a clear boundary around ... (see below)
>
>>As for the family of formats, my compromise is to allow each module to
>>extend the format as needed internally, but all external interactions
>>will use the standard format. This is dubject to change, but is
>>working well for the cases being tested.
>>
>If you can draw a clear boundary around each of the geometry and other
>information types in your storage method, they could be translated into the
>family of file-formats fairly easily. Each of the programs using a universal
>kernel would of course load the data into memory in their own preferred
>method, but a design like the one you are describing would be more easily
>transferred into running on such a core.
>
>--Eric
>
Other related posts:
