IDE Minutes 2007-08-09

From MemberWiki

Jump to: navigation, search

URL: http://www.openajax.org/member/wiki/IDE_Minutes_2007-08-09

Attendees this week

  • Jon Ferraiolo <jferrai(at)us.ibm.com>
  • Kevin Hakman <khakman(at)tibco.com>
  • Phil Berkland <berkland(at)us.ibm.com> representing Eclipse ATF project
  • Lori Hylan-Cho <lorihc(at)adobe.com>
  • Ludovic Champenois <Ludovic.Champenois(at)Sun.COM>
  • Greg Murray <greg.murray(at)sun.com>
  • Ingo Muschenetz <ingo(at)aptana.com>
  • Anne (?) - Microsoft

Minutes

(continuing to review and finalize http://www.openajax.org/member/wiki/IDE/requirements. Jon updated the document as decisions were made in the meeting.)

Kevin talks a bit about server frameworks wrt AJAX controls

Discussed Server framework integration section of requirements

  • Kevin: should we even take this on? should we only focus on client-side requirements?
  • Jon: we need to understand what it means, client side vs. server side. Microsoft AJAX, Lazlo, Flex are all hybrids.
  • Greg: We're not as server-centric as you might think; we're agnostic.
  • Ludo: We support many different servers. It's important to support server-side components, using metadata.
  • Kevin: Requirements are being developed from a client-side view; are these suitable for server-side? Are there specific requirements for a server-side environment that we should enumerate here?
  • Jon: I think these bullets look good.
  • Phil: It sounds like we're saying that we should design APIs. Aren't we just talking about metadata? (change made)

Two bullets in this section approved.

Discussed Dependencies section

  • Phil: First bullet sounds like a repeat of "SHOULD describe the resources upon which the control depends (other ajax libraries or controls). The minimum version number of those resources SHOULD be specified. There SHOULD be a mechanism for describing "depreciated" items (methods, properties, etc).."
  • Kevin: Versioning seems like a can of worms; can we describe this in text.
  • Jon: I agree; maybe we should have a MUST describe in text, and a MAY describe for automatic consumption.
  • Kevin: Added new bullets.
  • Lori: This is key for us: we need to know which asset files the widget/control depends upon.
  • Jon: I was thinking of it in terms of "Scriptaculous depends on Prototype".
  • Kevin: But I think Lori has a point here; we need to think about it both ways.
  • Jon: I'd be interested in the JMaki guys' experience, since they've already done this.
  • Greg: Yes, we do have this notion -- we group them into CSS, JavaScript, other assets. We *have* to have these things in order to copy the files to the right place and, if possible, render the widget.
  • Lori: This is exactly what we need, too.
  • Kevin: (changed the bullet under Phil's name that talked about dependent files to a MUST and moved it down to Dependencies section.)
  • Kevin: There's two different use cases here: Person reading file to see what's needed to run the widget, and Tool installing widget and dependencies.
  • Kevin: I propose adding another bullet to this section: "The metadata SHOULD seek to describe dependent resources in a way that could be shared between controls."
  •  ?: I'm wondering if we could use various hub... ? (Didn't get)
  • Lori: what's the hub?
  • Jon: It's a pub/sub mechanism developed here at OAA where different libraries can talk to each other.
  • Kevin: I've added another bullet to the bottom of the list about including the unique identifier for a toolkit as listed in the official OpenAjax Registry

(Discussion of revised bullets)

  • Jon: (withdrawn)
  • Jon: Let's move the "Toolkits SHOULD describe if they are dependent on a particular server framework (and thus perhaps trigger a download/install or vice versa)" to the parentheses in the third bullet.

Six bullets in this section approved.

Discussed Discovery and download section

All agree that first three elements should stay MAYs, but need to be reworded.

  • Greg: I like the idea of adding a section on design-time dependencies (as opposed to runtime dependencies).


Wrap-up:

  • Kevin: If anyone has actual examples of implementations, please share them.
Personal tools