Archive for May, 2004

Flex EULA

I was just reading through the Flex EULA (reading EULAs has become a hobby of mine, it seems) when I came across an interesting snippet under the section titled "Ownership":

"The foregoing grants of rights give you limited license to use the Software. Except as expressly provided in this Agreement, Macromedia and its suppliers retain all right, title and interest, including all copyright and intellectual property rights, in and to, the Software (as an independent work and as an underlying work serving as a basis for any improvements, modifications, derivative works, and applications you may develop), and all copies thereof. All rights not specifically granted in this EULA, including Federal and International Copyrights, are reserved by Macromedia and its suppliers." [Emphasis mine]

I am sure that it is just my laymen's reading of this that is wrong but this paragraph seems to suggest that Macromedia will own the copyright and intellectual property rights to any "applications you may develop" using Flex. Again, I am sure I am reading this wrong and I am sure that someone from Macromedia will confirm that it is not so but perhaps it might be prudent to change the wording here so that non-lawyers like myself will have no cause to worry.

Grant Skinner’s Workshop in London a big success

Emilie and I just returned from drinks with Grant (and his lovely girlfriend, Bobi) and the participants of the three day workshop Bits And Pixels Training organized here in London. Judging by the happy faces and the wonderful comments, the workshop was a great success! A big thank-you to Grant for his tireless 9-hour days and to all our participants for making it possible.

EULA questions on FlashPaper branding and customization

Macromedia FlashPaper is a very exciting tool for "printing" SWFs from any application (it ships as part of Contribute 2 and is not available by itself.)

FlashPaper is initially aimed at the consumer market for creating standalone FlashPaper SWFs -- which will, Macromedia must hope (and I believe), eventually replace PDFs. That's not, however, the use case that concerns me currently. What is infinately more exciting to a Flash developer is the ability to include external FlashPaper SWFs in your own applications, thereby transforming FlashPaper from a standalone PDF alternative to a truly embeddable PDF alternative -- a document display component for Flash, if you will.

The advantages offered by having a simple and accurate document display component for Flash are clear. What doesn't appear clear currently (since the release of the FlashPaper API) is whether or not developers are allowed to brand (or remove branding from) embedded FlashPaper SWFs and the extent to which they are allowed to alter the UI of an embedded FlashPaper SWF.

It would seem logical that developers looking to integrate Flashpaper into their Flash applications as a seamless element will want to brand and/or remove branding from the FlashPaper SWF and/or alter its UI to fit the appearance, flow, etc. of the UI of the greater application. The current MM EULA states that the interface cannot be altered. This is a prohibition that the Flashpaper API itself, it would seem, contravenes as it *does* allow parts of the UI to be turned altered (for example, the page navigation, print and zoom controls and be shown/hidden using provided public methods.)

The EULA states:

3. License Restrictions
n. Notwithstanding anything herein to the contrary, you may not (A) install FlashPaper Printer on a server for multiple user access or use, or (B) modify or replace the FlashPaper Printer viewer user interface that displays FlashPaper documents.

In many cases, having a Macromedia FlashPaper branding clip hotlinked to macromedia.com in a FlashPaper SWF that is embedded within a greater application is not desirable (if only because it adds to the noise of the greater UI, allowing one more point of confusion for your user.)

Ideally, developers should be able to alter an embedded FlashPaper SWF's UI without restriction to allow them to skin the component and integrate it fully with their application UI. A fitting requirement here would be that the developer is mandated to include the Macromedia Flashpaper copyright (or a "Includes Macromedia FlashPaper technology" message of some sort) -- hotlinked to macromedia.com, if necessary -- in her application's About box or in the credits or wherever the application's copyright message resides. Anything more than this would probably be a hindrance to the adoption of FlashPaper as an embedded element and I believe that it is as an embedded element that FlashPaper could most benefit Rich Internet Applications. It is also my hope that Macromedia will allow developers to license FlashPaper for server-side use. After all, why restrict this through the EULA when you can make money from it by licensing it?
Everything in an externally-loaded FlashPaper SWF can be manipulated through ActionScript, of course (so there isn't a technological barrier to not being able to modify a FlashPaper SWF's UI.)

e.g. (Where the "inner" movie clip contains the FlashPaper SWF)

// hide the toolbar:
_level0.outer.inner.toolbar_mc._visible = false;

// hide the branding clip:
_level0.outer.inner.toolbar_mc.brandClip_mc._visible = false;

// change the branding URL:
_level0.outer.inner.brandURL = "http://www.google.com";

It would be great to know what Macromedia's view towards this issue is. Is there a specific license developers can buy in order to legally brand FlashPaper SWFs (or hide their branding) and/or alter FlashPaper SWF UIs beyond what is currently possible with the public API?

The current trend appears to be towards opening up FlashPaper to developers -- a move I wholeheartedly applaud. I hope that this issue with the EULA will be cleared up as well so we can proceed with integrating FlashPaper into our applications without EULA worries (let's not relive the Flash component EULA issues -- once was more than enough!)

Grant Skinner and Mike Chambers tonight

Grant Skinner and Mike Chambers will be presenting at the London MMUG tonight. We have about 70 people registered -- looks like it's going to be a really good meeting and we've got a busy day planned!

You can find directions and full details on the MMUG web site.

Tomorrow: World-wide User Group Meeting

We're going to be hosting the Macromedia World-wide User Group Meeting in London tomorrow. Don't forget to sign up if you haven't done so.

I just spoke with Grant about an hour ago and his plane should have just taken off from Canada en route to London. He's going to be presenting alongside Mike Chambers (who will be arriving on Thursday) at Thursday's MMUG meeting. We've already got lots of people signed up for both events and I have it on good authority that Peter Hall, Guy Watson and Owen van Dijk will be among those in attendance. I have a feeling it's going to be a great event followed by interesting conversations at the pub.

VBulletin 3 Level Forum Home Hack

I just released a simple hack that allows VBulletin to display 2nd-level subcategories (i.e., a 3-level forum listing) on a forum's home page.

[Update] Collapsing/uncollapsing of parent and child categories does *not* work as expected. My initial fix only worked for 2nd level categories that only had a single forum. I've reverted the templates so that they now work with multiple 3rd level forums but collapsing a parent category does not collapse the children alongside. It looks like I need to dig deeper into the code to fix that.

Please read the notes on the thread at Vbulletin.org for background and installation information.

Please note: The hack is available for download at VBulletin.org for registered VBulletin owners only (their policy, not mine -- but it *does* make sense!)

I wasn't able to attach the screenshot (the upload form kept giving me errors) at VBulletin.org so I've added it here instead (click on the thumbnail to see full version.)

London MMUG double-whammy

We have an exciting week planned here at the London MMUG with two meetings lined up as part of Macromedia's Community Week.

On Wednesday we will be hosting the World-wide User Group Meeting through Breeze Live and on Thursday we have Grant Skinner and Mike Chambers presenting at our regular monthly meeting.

Grant will go on to teach a three-day workshop from May 24-26th.

Peter Hall, Owen van Dijk and Guy Watson, among others, will be coming over to attend the event so we can pretty much guarantee some lively conversations.

I've heard rumours that Guy (FlashGuru) will be bringing over his stash of Flash books and other goodies to add to the raffle. Thanks man!

Staying on with ColdFusion thanks to Prismix

We've scrapped plans to move the MMUG web site to PHP (whew, that was going to be a lot of work) and will be staying with ColdFusion thanks to Prismix who run our sister user group, UK CFUG. Prismix will be hosting and maintaining the UKCFUG and MMUG web sites on their dedicated server which should offer a nice, stable solution.

Thanks guys!

On the highly controversial decision to move the London MMUG web site to PHP

Following the 1.5 day outage at the MMUG (and similar troubles reported at the Netherlands MMUG), I've begun efforts to move the site to our own servers and to port the backend from Coldfusion to PHP. Of course, this decision has led to the rising of tempers in certain quarters: How can an MMUG move from CF to PHP? It's sacrilegious! Well, actually, it's not and, as I'll show you below, it's actually much better for the reputation of Macromedia that we do so. I see you confused and asking how that could be. The reason is quite simple:

ColdFusion and shared hosting simply do not go together. (And we cannot afford dedicated ColdFusion hosting for the MMUG at the moment with our current budget, nearly all of which is spent on room and refreshments costs for the various meetings.)

You only have to read through the ColdFusion support forums on Macromedia.com to see the plethora of issues surrounding shared ColdFusion hosting. Sure, you may want to get a shared account to develop, test, perhaps even stage on but deploying a CF application on a shared host when you expect a certain level of traffic can be a prelude to disaster.

J2EE and ColdFusion are great for Enterprise applications because of their scalability. ColdFusion has the added advantage of ease-of-use and lower development time. J2EE itself (which ColdFusion is built on) is not as performant as other application servers such as PHP due to the additional overhead it requires. In an enterprise setting this is not something you would care about since you can cluster several machines together and scale your J2EE/CF application to handle any conceivable load. In a shared server environment, where you have no such option, you will be better off going with a PHP-based solution which will let you get the most out of the limited resources you have at your disposal.

We are moving the MMUG website off of ColdFusion so as not to give the following false impressions about ColdFusion:

1. ColdFusion can (and should) be used on shared servers.

It was never meant to be and that's not its intended use. CF/J2EE cannot be all things to all people. It shines when used on dedicated machines where it can scale through clustering and decrease development time due to its ease of use.

2. Community sites routinely use ColdFusion.

Let's face it: They don't. How many community sites not subsidized in some way by Macromedia do you know that use CF? Such sites mostly use open source application servers due to budget constraints.

3. ColdFusion cannot handle the load (when the site goes down)

Having a ColdFusion site go down for two days does not do any favors to the reputation of Macromedia. It is better to not have the site in CF rather than to have it in CF and have it go down because we do not have the necessary infrastructure or budget to support a true CF solution (which, in this case, would require a dedicated server for the MMUG website.)

Lest it be understood that way, let me clarify once and for all that our move from CF to PHP for this website has nothing to do with CF not being able to handle the load: It is because CF cannot handle the load on a shared server -- a setup it (and J2EE) was never designed to work on and should never be deployed on.

By rewriting the site in PHP we will have a site that is stable under a shared hosting environment and one that we will be able to maintain and control. This will mean that we will be able to maintain a high level of service without stretching the limited budget we have for the MMUG.

The next month or so will no doubt be a tumultuous one for the MMUG web site but we are working hard to have it up and running again as soon as possible.

In the meanwhile, we are having two amazing meetings this month: On the 19th and 20th of May. The Worldwide User Group Meeting is on the 19th and Grant Skinner and Mike Chambers will be over to present on the 20th.

MMUG web site outage

I must sincerely apologize for the London MMUG website outage. Unfortunately, the site is not being hosted by our own hosting service and we have to go through an intermediary to get things sorted out. Needless to say, the site will be moved onto our own servers and onto a much more stable system administered by us in the coming days.

In the meanwhile, if you wish to sign up for the world-wide MMUG meeting on the 19th or the Grant Skinner/Mike Chambers meeting on the 20th (or both), please add your name to the comments, specifying the 19th, 20th or both (eg. Aral Balkan - Both).

Again, I apologize for this.






Bad Behavior has blocked 0 access attempts in the last 7 days.