#9 ProgressMonitor Interface instead of getProgress()


It would be nice to pass a monitor interface to the DAE::load(daeString, daeString) method instead of doing this in a thread and calling DAE::getProgress(daeInt*, daeInt*,daeInt*,daeBool).

DAE::load(daeString, daeString, daeProgressMonitor*)

class daeProgressMonitor
loaded(daeInt* bytesParsed,
daeInt* lineNumber,
daeInt* totalBytes) = 0;

BTW: Is the DOM thread safe?


  • Steven Thomas

    Steven Thomas - 2007-12-10

    Logged In: YES
    Originator: NO

    Yeah, our progress monitoring isn't functional at all right now. We should fix that.

    "BTW: Is the DOM thread safe?"

    No. I'm not sure if that'll ever change. Before it was basically hopeless, because there was too much shared state and global variables in the DOM. But I'm doing a massive architectural renovation job in the "multipleDaeCrash" branch that splits up a lot of the shared state and removes global variables. After these changes it'll be plausible to bring the DOM to thread safety, so that e.g. you could use multiple DAE objects to load multiple files at once. Unfortunately there's still going to be some global state (the string table, specifically) that can't easily be removed and will require locking to synchronize access, which might destroy any benefits that could be obtained from multi-threaded document loading with the DOM.

    But we are sort of moving in that general direction.


  • Steven Thomas

    Steven Thomas - 2007-12-10
    • assigned_to: nobody --> steve314
  • Nobody/Anonymous

    Logged In: NO

    Hey Steven, happy new year! How is your job with the massive architectural renovation doing? Our team is going to use the current svn head to make our software compile and work under linux. Regards, Kai

  • Steven Thomas

    Steven Thomas - 2008-01-07

    Logged In: YES
    Originator: NO

    Thanks, happy New Year to you too!

    The big architectural changes were merged into the trunk in revision 353 on Dec 21st 2007. Your code may require a few tweaks, particularly where daeURIs are concerned. They now need either a daeElement or a DAE object in their constructor.

    I'm planning a DOM 2.0 for early this year, hopefully in the next month or so. I still have to look at the charEncoding branch (which contains the patch you submitted) and figure out if that's safe to merge back to the trunk. The current svn head should be very stable, but if you have any problems let me know.



Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks