Ocornu Webmonkey → 0.1a2

Comments and changes to this ticket

• 

  Olivier Cornu March 29th, 2009 @ 11:09 PM

  • State changed from “new” to “open”

  Things have already started. Not sure if it will be completed for the next milestone...

• 

  Olivier Cornu April 20th, 2009 @ 12:40 AM

  • Milestone set to “0.1a1”

• You flagged this item as spam.
  

  oyasumi (at gmail) May 4th, 2009 @ 12:28 AM

  Is it mostly a structural and code cleansing thing, at this time, or does it include backing out of bad design decisions, like how the manager keeps memory state, rather than reading on-disk configuration as the authoritative state of reality?

  (The step back that doesn't let us edit an @include rule on-disk and hope to see changes in Firefox, as that now resides in memory instead.)

• 

  Olivier Cornu May 23rd, 2009 @ 10:18 PM

  Hi Johan, nice to see you here. :-)

  At this time it is mostly a structural cleaning (with added
  documentation). I'm gradually factorizing code in classes with cleaner
  interfaces, using JavaScript Modules (FF3.0+ feature) -- basically,
  code migrates from chrome content dir "flat library" files to the
  modules directory. However, i do it with the features/changes i plan
  to introduce next in mind.

  Among those changes is the "memory state" issue you're talking about.
  I believe there is too much metadata redundancy between config.xml and
  script content. Metadata that cannot be user-customized (@name,
  @description...) should only live in script files. It means webmonkey should update its state whenever one of these files change. Customized
  metadata/user settings (@include/@exclude, enabled states...) should
  live in prefs.js with other user data (GM_values). Altogether, that
  means no more config.xml file.
  This way, disk state becomes authoritative (updating an @include rule
  in a script file will impact the running FF immediately), unless it is
  overridden by user-settings.

  I only see advantages to this architecture: the file-system footprint
  is simplified (one subtree of script directories, no user-specific
  config.xml), clean separation between "public" and "private" data
  (script files vs. user settings) thus the scripts directory may be shared between users/profiles...
  Does it look like what you had in mind?

  By the way, i'm sorry it took me so long to answer: this is quite a
  busy month, i'm not home and i often don't have internet connection...
  :-p

• 

  Olivier Cornu August 24th, 2009 @ 08:45 PM

  Webmonkey core code refactoring is now well on its way and i'm getting closer to the end (the reference documentation has been updated: http://ocornu.github.com/webmonkey/doc/index.html ).
  UI code has not been much touched yet, although namespace pollution has been significantly reduced. Given that i'd like to tweak the UI in the near future, it will have to wait for this day.
  Running WM and GM on the same FF profile is only possible if you disable the one you're not currently using. That's how far it will go for the moment. :-p

  I believe it's time to start thinking about new features! :-)

  I'm really willing to make progresses in order to make script developers life easier. More powerful debugging features is a good start. A better synchronization between WM and its share of the file-system would be a nice bonus. I strongly believe in inter-scripts communication and dependency: done right it would make it easier to build bigger and more stable client-side apps. The ability to safely publish/install script updates would be a huge improvement in terms of community dynamism. And tons of others...

  I believe scarcity lies on the developers side and, despite the great number of existing scripts, that's where overall gains await. :-)

• 

  Olivier Cornu August 29th, 2009 @ 07:18 PM

  • Milestone changed from “0.1a1” to “0.1a2”

  Pushing back further refactoring to 0.1a2