[OpenAjaxIDE] <required>: type=library|folder

Jon Ferraiolo jferrai at us.ibm.com
Fri Jul 18 08:51:07 PDT 2008

One of the open topics from this week's phone call was a response to Lori's
email (http://openajax.org/pipermail/ide/2008q3/000539.html):
So, given the above, I have a couple questions:

1. What exactly is meant by "loading"? Does it mean that the IDE would
not add the same file to the head twice? If so, I think we can handle
that part. If, however, it means that the same asset should not appear
in multiple places in the user's site, that's a problem. I'm hoping it's
the former, but that still brings up point 2:

2. How would we know whether the dom.js file that's included with the
FooCalendar widget is the same dom.js file that's included with the
FooPassword widget? Is there some assumption we should be making here,
in the absence of any indication that FooCalendar and FooPassword are,
actually part of the same library? Would the expectation be that dom.js
be specified with <require type="library" src="dom.js">, and that this
is how one would indicate "shared" files? If this is the case, then it
seems to me that the name attribute (the name of the library) and
possibly the version attribute might still be required in addition to
src to help determine whether the file in question really is the same as
another file of the same name.

I studied a few major toolkits and thought things over. One observation is
that it appears that major Ajax libraries support a workflow where you copy
their entire Ajax library onto your Web site, which potentially wastes disk
space on the server, but they all have modularization techniques such that
when your web page runs, only the modules that your web page needs are
downloaded over the wire. For YUI and ExtJS, the standard way of pulling in
only those modules that you need is to manually insert script tags for
those modules. For Dojo, there are multiple advanced options due to their
build system, but the "normal" way of using Dojo is to include a script tag
for "dojo.js" and then call "dojo.require(...)" to identify the modules
that you need, and then Dojo will pull in those modules for you. (I believe
the normal approach for Prototype and jQuery, which are relatively small,
is to simply source in the single JS file that contains the whole library.)

Here is what I am thinking:

1) We don't need a 'shared' attribute. Instead, if 'name' is supplied, then
that indicates that an asset is subject to sharing.

2) As Lori suggests above, if type="library", then a properly constructed
metadata file SHOULD include a 'name' and a version attribute so that tools
can determine shared usage of the same library and install it only once
within the distribution directory structure. (Note: I have questions about
'minVersion' below in #4 below. Regarding 'folder', see #7 below.)

3) As Lori suggested in the phone call, from a processing model
perspective, 'library' and 'folder' amount pretty much to the same thing: a
copy operation on a folder. In fact, the 'name' attribute might make sense
for 'folder' even when referring to something that isn't a JS library so
that a particular folder can be shared across multiple widgets. (But before
getting too far in that discussion, we need to talk about 'minVersion': see
#4 below.)

4) But now onto 'minVersion'. I am wondering what we really need from a
version attribute. Do we need to identify which *range* of library versions
that are compatible with this widget, or do we need to specify what *exact*
version number is for the library that is referenced by the 'src'
attribute, or both? There are usually too many dependencies between widgets
and libraries such that a particular widget will often only work with only
one particular version of a library, or (for widgets defined by a 3rd party
on top of a particular library) a particular generation of a library (e.g.,
Dojo 1.1.x). Here is what I suggest we do - two version attributes for
<require type="library">:

* 'version' indicates the exact version number for the library that is
referenced by the 'src' attribute. For example, if the 'src' attribute
references Dojo 1.1.2, then the element would look like:
<require type='library' name='dojo' version='1.1.2' src='...' />

* 'compatibility' indicates the range of library versions with which the
widget is compatible. For example:
<require type='library' name='dojo' version='1.1.2' src='...'

5) So that widgets will use a standardized approach to library names, the
'name' attribute for a library should refer to a registered name with the
OpenAjax Registry.

6) We need to have a well-defined processing model if attributes 'name',
'version' or 'compatibility' is missing. One option is to treat as an
error, but error situations are usually messy, and usually better to figure
out defaults for missing attributes. Here is my proposal:
* If 'name' or 'version' is missing, then there is no sharing. (The spec
would need to include strong recommendations about having 'name' and
'version' attributes and include warnings about potential file duplications
and potential file collisions if these attributes are not supplied.)
* If 'compatibility' is missing, we default to the range 0:infinity.

7) As I mentioned in #1 above, 'library' and 'folder' are very similar and
in fact could probably be merged. My proposal, however, is to have two
separate keywords because of the semantic value of the word 'library', but
otherwise the two options share the same attributes and have the same
processing model. Therefore, it is possible to use 'name', 'version', and
'compatibility' on a 'folder' (although for type='library', the 'name'
attribute does not have to refer to a name from the OpenAjax Registry). The
spec would point out these similarities and tell metadata authors to use
'library' when referring to an Ajax library and use 'folder' when referring
to a folder that isn't an Ajax library.

8) I think it makes sense for 'name', 'version' and 'compatibility' to also
work with the other types (e.g., type='javascript') so that a tool can deal
with sharing of individual files, not just folders.

I am not sure the above addresses all of the issues that Lori brought up on
Tuesday. Lori, what did I miss?,

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/ide/attachments/20080718/12e033c9/attachment.html 

More information about the IDE mailing list