Any objection? Checking in a roll-up

[John Boyer]

The performance of UX is frequently being misjudged because people try our samples from the code project based on links to the unrolled processor.

Ultimately, we'd like to have buildbot automatically checking in updates to the processor, but until that happens, it would still be very handy to have a copy checked in that the examples can be pointed to.  We can manually update it as needed until the automated process is there.

Any objections?

Thanks,
John M. Boyer, Ph.D.
STSM, Interactive Documents and Web 2.0 Applications
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boy...@ca.ibm.com  

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed: http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw

[Mark Birbeck]

Hi John,

I'm pretty sure we'd already agreed to do that. :)

The reason I'm sure, is because just after we agreed to it (on a
telecon), it occurred to me that the best place for the roll-up file
is actually the Download page! So thanks for reminding me.

The first thing is that I'd previously hidden the "Download" tab,
because I didn't think we needed it. I've now switched it back on, and
you can go directly to it here:

<http://code.google.com/p/ubiquity-xforms/downloads/list>

Next, click on "New download", and enter a description, such as
"Roll-up for version x".

In Labels, if you add "Featured", you'll automatically get a link to
the download on the home page, in the same way that we do for wiki
pages. However, I'd suggest we keep that for something more
substantial, like a zip file of all the files for a particular
version.

Finally, the issue of the file name; we would need to call the roll-up
file something like "uxf-0.7.0.js", for two reasons.

The first is that Google recommend that you don't overwrite files that
have been placed in the download section, but just keep adding to the
list with new versions. We follow this approach on the formsPlayer
project and have downloads like "formsPlayer-1.2.3.4.msi".

(When you want to hide a download from the list, you just give it the
label "Deprecated"; but it would still be available to any project
that referred to that version.)

The second reason is to do with library performance; I've been doing a
lot of reading around on the question of deployment and performance,
because it's not going to be long before we have some real projects
using UXF, and it turns out that 'best practice' is to set your server
caching such that you have a very long expiry time, but then to have
version numbers on the file names.

(You'll probably recognise that pattern from the YUI library file names.)

This means that if someone puts "uxf-0.7.0.js" onto their server, and
then sets the file to have a long expiry (and by long I mean something
like five years!), people who use their application regularly will
never reload it. But if they move to a new version, it's still
possible for them to force browsers to download it, by upgrading to
"uxf-0.7.1.js", or whatever.

And of course it means that one application could be using 0.7.0 and
another could be using 0.7.1.

By the way, I don't have a preference for the prefix part of the name
-- I'm just saying "uxf" to make it easy to give examples. But I would
recommend that we don't use "-loader" in the name, since it's not
really applicable with a roll-up file.

One last thing, on Buildbot -- the roll-up creation was working, but
when we launched a new instance on Amazon, we obviously missed a vital
piece of our configuration, so it's failing. It's going to take us a
little tweaking to get it going again, but hopefully we'll get it
sorted soon.

Regards,

Mark

--
Mark Birbeck, webBackplane

mark.b...@webBackplane.com

http://webBackplane.com/mark-birbeck

webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)

[Erik Johnson]

Do we want the roll-up uploaded as only the single file or a directory with the entire structure? ie the dist folder zipped and renamed or just the ubiquity-xforms.js renamed from the rolled up package folder?

Erik

[John Boyer]

Hi Erik and Mark,

Erik, there isn't enough detail to understand your question on its own.

Mark, I like the idea of putting a versioned rollup into the downloads area.
However, what I had in mind here was to check in a rollup into the samples directory so that all samples could relatively reference it.
Granted it would change periodically when new rollups are checked in, and there would be some concern about stability of examples, but someone concerned about stability would simply access the examples  from a tag rather than from the trunk.  Can you live with that?

Thanks,
John M. Boyer, Ph.D.
STSM, Interactive Documents and Web 2.0 Applications
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boy...@ca.ibm.com  

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed: http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw

From:	Erik Johnson <eri...@gmail.com>
To:	ubiquity-...@googlegroups.com
Date:	11/12/2009 08:50 AM
Subject:	Re: Any objection? Checking in a roll-up

---

[Mark Birbeck]

Hi John,

I don't mind. :)

I have a completely different technique for doing this, which is much easier, and I'm hoping to introduce it to you all in a week or so. It's basically a result of looking at how a number of other libraries do it, and I have to say it's much easier.

But by all means, do whatever you need to do, now.

Regards,

Mark

[Nick Van den Bleeken]

Hi John,

 

I don’t want to interfere too much, but you need to be really careful with letting the examples point to a javascript library without a version number in the filename. Browsers tend to ignore the last change date of a javascript file (IE for example never goes and ask if a js file is modified if it cached the file before). This will require users of clear their browsers temporary internet files (cach) before they are sure they have the latest version of the ubiquity library.

 

That is why libraries like yui, dojo, jquery,… have version numbers in their file name. I just want to be sure that you know this in advance, so you don’t make the same mistake I made a couple of years ago. When you have a modular version of your library you should always append ?n to the javascript url’s when fetching them, with ‘n’ the version number, for the same reason as in the rolled-up version.

 

 

Regards,

 

Nick Van den Bleeken

R&D Manager

 

Phone: +32 3 821 01 70

Office Fax: +32 3 821 01 71

Nick_Van_d...@inventivegroup.com

http://www.inventivedesigners.com

 

--
This message has been scanned for viruses and
dangerous content, and is believed to be clean.
--

---

Inventive Designers' Email Disclaimer:
http://www.inventivedesigners.com/email-disclaimer

--
This message has been scanned for viruses and
dangerous content, and is believed to be clean.
--

[John Boyer]

Hi Nick,

Well, this is actually a good point, thank you.

But...

I'd like to be able to cut a new roll-up and check it in at will without having to create a new public download entry. Anyone operating off the trunk would be doing something experimental anyway, and cache clearing could just be expected.  Typical debugging sessions on a sample would likely have the developer flipping back to the unrolled code anyway, and we already reference the unrolled processor without version number in our samples anyway (so we're already in for a penny, so to speak).

I am wondering whether the point you raised would negate my prior claim/belief that once a tag was made, then a sample loaded from that tag would be stabilized to using the rollup in that tag?  Even if the tag had the exact same name for the rollup file as did the trunk, wouldn't the browsers still load it anew because the absolute path to the tag's rollup differs from the the trunk's rollup?  I think it would be OK because of the change of absolute path, but let me know if this is incorrect.

And regardless of the answer, there is no downside to checking in a rollup on trunk without version number, relative to what we're doing now, and there is an upside of dramatic speed increase and high responsiveness to bug fixes that make it to trunk (with the proviso of possibly needing a browser cache clearing).

Cheers,

[Mark Birbeck]

Hi John,

I've said before that I don't agree with having generated files under version control, but since we don't have the solution in place that I'd actually like to see, then I'm hardly going to argue against you checking in the odd file.

But it's probably best not to have a discussion about the pros and cons, because I disagree with pretty much everything you've said below. :)

So if you want to check a roll-up into trunk, just go for it.

Regards,

Mark

--
Mark Birbeck, webBackplane

mark.b...@webBackplane.com

http://webBackplane.com/mark-birbeck

webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)