[Dev] OSAF Office Hours (Development environment) 11 AM PST 13 April Wed

[Donn Denman]

I've been trying to develop a parcel, using only the information 
available on the web.  Here are a few of the issues that were tough for 
me, and a few ideas for improvement.  See my list below.

- Donn Denman

On Apr 12, 2004, at 3:14 PM, Ducky Sherwood wrote:

> This is a reminder that the next OSAF Office Hours will be this 
> Wednesday, 13 April at 11 AM Pacific time (18:00-19:00 GMT/UTC/Zulu).
> This week, the Applications Group would like to brainstorm on ways to 
> make our development environment more developer-friendly.

1) The repository is great, but it complicates development:
     - your code needs to work in 3 cases:  data present in the 
repository, data absent, and even when there is obsolete data there.
     - it's not immediately clear to developers which things are 
persistent, and which are transient.
     Suggestions:
     - since running from scratch isn't much slower, it simplifies 
initial development to stick with this single mode.
     - there should be a convenient way to clear the repository to speed 
development, e.g. "quit & clear" menu item.
     - a repository user's guide would solve most of this.  I figured a 
lot of it out through trial and error!

2) The development cycle time is very slow, especially for people 
without great XML or Python skills.
     - Each launch of Chandler takes a long time, and usually yields 
only one single error
     - Once you get past the syntax problems, WingIDE can be a big help 
- if you know how to use it
    Suggestions:
     - Turn on the Debug Console in the project that you distribute.  
Without the console, "print" is silent, and often exceptions are silent
     - Batching up errors, by letting the XML parser to continue after 
an error would be good
     - Consider providing a "toy" Chandler, that is fast but brainless, 
would help us get past the syntax problems quickly
     - A development tool for graphic authoring of UI, that generates 
correct XML would be great
     - Better documentation and rich examples always help

3) It's hard to know what all the magic XML terms are.  I initially 
relied on examples, but now I know to look in:
      - parcels/framework/blocks/parcel.xml   for block stuff
     - repository/schema/parcel.xml for  core types
   Suggestions: this may already be on the web, but it was not simple 
for me to find and use

4) Fixing bugs.
     - There seems to be a problem with a try block catching runtime 
errors, so they are silent if the console is not up.
     - The bug 1177 warnings are worrying to folks like us

Overall I have both loved and hated Chandler parcel development.  I 
think the code quality is quite high -- there are relatively few bugs 
and Chandler almost always does what it's supposed to do.  It just 
takes so long.


>
> Please join us!
>
>
> As always, our Office Hours are at irc.osafoundation.org, channel 
> #chandler.
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/dev