IDE Minutes 2007-12-13

From MemberWiki

Jump to: navigation, search


Attendees this week

  • Lori Hylan-Cho <lorihc(at)>
  • Kevin Hakman <khakman(at)>
  • Jon Ferraiolo <jferrai(at)>
  • Bertrand Le Roy <Bertrand.Le.Roy(at)>
  • Stew Nickolas <nickolas(at)> (QEDWiki)
  • Phil Berkland <berkland(at)>
  • Scott Richards <srichar(at)>


Kevin: Has anyone done any further work on trying to write up...?

Stew: I did a mapping/diff between the Gadgets Metadata Strawman proposal and the Widgets Metadata Strawman that Jon wrote up. Took a Google Gadget xml and transformed it into OOA Gadget Metadata.

Jon: Eventually we'll probably want to unify these strawman proposals, since there's a lot of overlap.

Stew: [Something about the adapter.] Words are great, but you need to test it out as you go.

Kevin: Gadgets tend to be mini-applications, whereas controls are more standalone and still have to be configured, programmed, instructed what to do. The Gadget work seems to be focused on a kind of runtime assembly, whereas the Widget/Control work is more around how to let a tool help a developer rig up a control.

Jon: ...are gravitating toward an approach that would allow for a unification of the different proposals. They're leaning toward constructors and divs with IDs and so on.

Kevin: On the subject of similarities and differences, Stew, can you talk about how the Gadget work relates to the Open Ajax Hub?

Stew: The Gadgets proposal we're coming up which can run on top of the Hub. [Didn't get all the details -- sorry, sick brain is fuzzy. :( ] Default IDE is a text editor. Grain size (?) of gadgets tend to be a little larger, but we're hoping to use the same metadata as we go up the chain. Gadgets need to have sort of a closure for security reasons. We anticipate that widgets will move around from one hosting environment to another. The pub/sub model is similar to how Google Gadgets have done their....?...when you want to publish a property value, you put publish=true or listen=true. All of this will boil down to a reference implementation that will run on the Hub. Using the eventing model of the Hub as well. Plugging into the Hub is very important and putting together a reference implementation is important as well.

Jon: So what this boils down to...

Stew: Semi-aligned with the Aptana approach with bag of properties. Constraints... let's think of backing off of developing a new kind of constraints and falling back to an xsd tool. Balancing a rudimentary property editor vs. letting the Gadget edit itself.

Jon: I wrote up this thing with jsType and xsdType, but we haven't really had any discussion around it, and a few people have objected to it. So that's wide open right now.


Jon: I think the whole datatyping issue needs more focus. We should have a meeting that's dedicated to issue #2.

[Some discussion about whether typing is really issue #2. May need to add another issue.]

Stew: So we're sort of punting on datatypes for now; we figured we could add something more elaborate later.

Jon: What do the IDE folks think about this?

Lori: Strings can obviously be text fields, but the type of string can really get you into trouble (IDs that must be unique, selectors that mean something, etc.)

Kevin: Plus, enumerations.

Scott: Exactly -- enumerations are really important.

Jon: It seems like there should be a fallback approach. If the metadata has too much information, the IDE doesn't need to use it; it can fall back to the main type.

Bertrand: We absolutely must have support for enumerations, arrays, etc., but it also seems like we need an extensibility mechanism.

Phil: What about just having a snippet of JS code that validates the value?

Bertrand: That doesn't help the user ENTER the value, though. You might want to have a collection editor, for example, that makes entering the value easier.

Jon: I can look into this and see if there's an answer that jumps out, and I can have that for next week.

Kevin: I think next week we can start diving into the individual topics. Or maybe now, since we have 20 minutes left.

Jon: Let's start with issue #1, since it was talked about a bit yesterday in the Gadget TF. [Jon walks us through The New Proposal in the issue #1 wiki page.]

Discussion about whether head="" covers the cases we want, and whether insertAt="head|body|null" would be more appropriate.

Kevin: What about the order in which the assets are referenced?

Lori/Scott: We assumed that the order specified would be the order added.

Stew/Kevin discussing whether "head" means PUT IT IN THE HEAD or the more generic PUT IT IN MEMORY FIRST. (Memory seemed to be the consensus.)

Stew: We need some way of sandboxing widgets, of saying that this widget cannot co-exist with some other widget with, for example, a different preload setting.

Jon: Yes, we do.

Stew: So we need metadata that could describe this sandboxing requirement.

Kevin: Can you take a stab at that?

Stew: I think it boils down to knowing when to create an iframe. ineedaniframe = "true" is one way, but you could also be reactive and let the tool say, "you've already got a gadget that has preload = false, so this one with preload = true needs to go into an iframe."

Kevin: I'm a little nervous about having 50 require statements for all the bits and pieces that a widget might need to run.

Jon: I think in that case you'd just point to the dojo or GI folder, rather than all the individual files, and let your application indicate which files from the toolkit it requires.

Kevin: So we are meeting next week on Dec. 20, and we'll talk about the datatyping issue. We'll skip Dec. 27 and meet again on Jan. 3.

Personal tools