lifecycle policy for XULRunner apps?
Fabien Cazenave
a lot has already been said/written about the pros and cons of the new
lifecycle policy. Nobody doubts it's a good thing for Firefox and the
web platform in general, but I'm worried about the consequences for the
XUL platform (and XULRunner apps in particular).
Does this new lifecycle policy means that all XULRunner-powered apps
should follow the 6-week pace? That would mean the end of this platform,
wouldn't it? If this requires to rebuild, test and publish an app every
6 week, that won't leave much time to work on the app itself...
I understand an LTS branch for XULRunner (and possibly Firefox) is a
significant workload, but as many contributors I've been interested in
the Mozilla project because it's much more than "just a browser". Most
XULRunner apps don't need the latest Firefox features but they do need
to get security updates for a significant time period -- say, one year.
Are there specific plans concerning XULRunner? Or should we consider
that XULRunner is deprecated?
Cheers,
:kazé
Benjamin Smedberg
> Does this new lifecycle policy means that all XULRunner-powered apps
> should follow the 6-week pace? That would mean the end of this
> platform, wouldn't it? If this requires to rebuild, test and publish
> an app every 6 week, that won't leave much time to work on the app
> itself...
we have never spent QA resources on it, and if it doesn't ship that
doesn't affect the schedule. The expectation is that most people who
ship XULRunner-based apps build it themself.
To the specific question, it really on your app. If your app is exposed
to web content, then you would either have to backport security fixes to
your current codebase, or update. The current plan does not have the
main Mozilla project backporting those security fixes. If your app isn't
exposed to web content, security bugs really aren't the same kind of issue.
>
> Are there specific plans concerning XULRunner? Or should we consider
> that XULRunner is deprecated?
There have never been specific plans concerning XULRunner. It has always
been a technology experiment that some people are building apps upon,
and they make decisions about how their apps are shipped and updated
independently of the main Mozilla release cycles. Obviously rapid
release will make that a more difficult proposition, but that is a
calculated tradeoff.
--BDS
Ben Bucksch
> If your app is exposed to web content
(which many or most are)
> then you would either have to backport security fixes to your current
> codebase
(which is impossible, given that the Mozilla security group with some
support by core devs didn't manage to do it, and that was a whole team)
> or update.
which is impossible for practical reasons, because these apps have a
release process as well. And they often have only a few devs. And their
users are often lazy to update, too. And often in the same enterprisy
situation.
One former XULRunner customer of mine is still running an old release as
base for their XUL apps, *which drive most of their business*, which has
10 digits. It's a company you may have heard of. I tried to get them
updated, but they won't (luckily without web content in this case. I
hope, but I'm not sure.), in part *because* it drives so much of their
business and needs to run in so many setups and places you don't even
imagine. Just to get the situation across.
Update more often than once a year is impossible.
> It has always been a technology experiment
No. XUL has very much been advocated as platform, in years past, by
mozilla.org leaders like Brendan Eich and others. Just because you
decided otherwise in recent years doesn't make all those apps go away
and be paid to be rewritten with some other toolkit. This is a
fundamental fact you fail to appreciate.
> Obviously rapid release will make that a more difficult proposition,
> but that is a calculated tradeoff.
A calculation that you made or that they made?
* They couldn't make the calculation, because nobody expected this
or even considered it possible, a year ago, much less 10 years ago.
* You cannot calculate on their behalf.
Ben
Ben Bucksch
> On 27.06.2011 22:01, Benjamin Smedberg wrote:
>> If your app is exposed to web content
>
> (which many or most are)
>
>> then you would either have to backport security fixes to your current
>> codebase
>
> (which is impossible, given that the Mozilla security group with some
> support by core devs didn't manage to do it, and that was a whole team)
>
>> or update.
>
> which is impossible for practical reasons, because these apps have a
> release process as well. And they often have only a few devs.
The QA resources alone, needed to verify the XULRunner app after a major
XULRunner update, are prohibitive for most apps and teams. They come in
addition to what I said before.
Also, download costs are significant, if you have 10 million users (like
TomTom HOME2, which I was responsible for) and you ship 10-20 MB every 6
weeks. That's close to 2,000,000 GB per year. Check the prices of
download accelerator services that big companies use and you have a price.
That traffic cost alone could pay a whole developer team at Mozilla
doing security patch backports.
And that's just one app. The same price has to be paid by each app. And
they have zero gain from this, just cost. Try to justify that with
management.
You see that users will simply be left insecure, plain as that. And
that's directly contrary to the Mozilla mission.
This decision just doesn't make *any* sense, if you take the whole
ecosystem into consideration.
It's not good for many conservative end users, not for existing (!)
corporate users, not for existing (!) XULRunner apps, all of which made
significant investments into Mozilla.
Ben
Axel Hecht
Did you just volunteer to recruit, hire, and pay that person that does
the backporting of security fixes?
Seriously, though: You're making a statement that there are folks out
there using Mozilla technologies and saving a shitload of money that
way. What is Mozilla getting in return?
Also, just because one thing is called 5 and the next thing is called 6
doesn't mean that you can't ship incremental updates for that. Like you
would have had to anyway, in case your xulrunner is webfacing, right?
Axel
Robert O'Callahan
> Also, just because one thing is called 5 and the next thing is called 6
> doesn't mean that you can't ship incremental updates for that. Like you
> would have had to anyway, in case your xulrunner is webfacing, right?
>
The incremental updates will be very large since the changes between full
releases will be much more than just security fixes.
Rob
--
"If we claim to be without sin, we deceive ourselves and the truth is not in
us. If we confess our sins, he is faithful and just and will forgive us our
sins and purify us from all unrighteousness. If we claim we have not sinned,
we make him out to be a liar and his word is not in us." [1 John 1:8-10]
Ben Bucksch
Did you read what I wrote? I wrote above that this is almost impossible.
Alex, I am trying to add very rational arguments. I would prefer we
could discuss on that basis.
Because I think it makes much more sense when Mozilla serves these
users. I said that this decision hurts users significantly, hurts people
building on the Gecko platform (be it Firefox or XULRunner), and
therefore is in contradiction of the stated and defined Mozilla
manifesto. See point 4 and my outline above why users will be left
insecure, in practice.
Ben
Wes Garland
> Are there specific plans concerning XULRunner? Or should we consider that
> XULRunner is deprecated?
>
I'm in a similar situation as a SpiderMonkey embedder.
As far as I am concerned, I'm grateful that moz exposes their entire process
(not just source code), so I have all the information I need to backport
whatever security-related patches I want -- and I understand the upcoming
API changes. This costs me signficant time each and every week, but at
least I get to hang out with awesome people on IRC in the process.
(Well, maybe not ALL the security patches, but at least all the public ones)
I think that this is the right approach for an application vendor who
depends on Mozilla code -- I can't rely on anything I can't control. The
alternatives are:
- partner with somebody who will promise to maintain a stable version for
you,
- Never expose your code to the 'net
- Keep your app on the bleeding edge
Wes
--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102
Benjamin Smedberg
>
> No. XUL has very much been advocated as platform, in years past, by
> mozilla.org leaders like Brendan Eich and others. Just because you
> decided otherwise in recent years doesn't make all those apps go away
> and be paid to be rewritten with some other toolkit. This is a
> fundamental fact you fail to appreciate.
that we started shipping in 2006 called "XULRunner". That was always an
experimental build and has never had QA resources.
>
>> Obviously rapid release will make that a more difficult proposition,
>> but that is a calculated tradeoff.
>
> A calculation that you made or that they made?
A calculation that the Mozilla project made.
--BDS
Sonny Piers
I won't debate about lifecycle policy here but Benjamin, you cannot
consider few employees of Mozilla Corporation taking a decision as the
"Mozilla project".
As contributors, the hundreds of volunteers thought they were members of
this project.
Cheers.
>
> --BDS
>
Benjamin Smedberg
>
> I won't debate about lifecycle policy here but Benjamin, you cannot
> consider few employees of Mozilla Corporation taking a decision as the
> "Mozilla project".
discussed, and adopted publicly on this list. It was made because "we"
the Mozilla project believe that our primary focus needs to be rapid
innovation and Firefox. That means that other possible priorities
(including XULRunner and the XUL ecosystem) are not as important.
This is not at all about employee versus non-employee status. It is
about how we as a project (not a company) make priority decisions. The
worst thing that can possibly happen is that we can't decide what's
important, and so we work on a little bit of everything, and don't do
anything well.
--BDS
Joshua Cranmer
> On 6/27/2011 6:41 PM, Ben Bucksch wrote:
>>
>> No. XUL has very much been advocated as platform, in years past, by
>> mozilla.org leaders like Brendan Eich and others. Just because you
>> decided otherwise in recent years doesn't make all those apps go away
>> and be paid to be rewritten with some other toolkit. This is a
>> fundamental fact you fail to appreciate.
> I'm not talking about 'XUL'. I'm talking about the reusable build
> thing that we started shipping in 2006 called "XULRunner". That was
> always an experimental build and has never had QA resources.
I want to refresh my memory... when the decision was made to drop
embedding of gecko, I thought that the response by Mozilla was to tell
people who wished to use gecko that they should use XULRunner instead.
Isn't that a tacit commitment to XULRunner as a product?
Jean-Marc Desperrier
> The decision to adopt a rapid release model was proposed, discussed, and
> adopted publicly on this list. It was made because "we" the Mozilla
> project believe that our primary focus needs to be rapid innovation and
> Firefox. That means that other possible priorities (including XULRunner
> and the XUL ecosystem) are not as important.
The rapid release model was very widely adopted here.
(and is a big success as of now, which is a big difference with how
plans to release fast have failed in the past)
But I think the current discussion shows the large community approval
was on "let's get a new release out every 6 weeks" part of the model,
not really on the "let's EOL every version except the very latest
release" because it's consequence of "let's pull the plug on the whole
XULRunner eco-system" (and almost all applications listed here
http://www.mozilla.org/projects/mozilla-based.html) was not really
realized by most.
I think a significant number of very competent Mozilla hackers entered
the community, or sustained their involvement in it, through this
eco-system. So the new policy could have bad consequences on their number.
Fabien Cazenave
> On 6/27/2011 6:41 PM, Ben Bucksch wrote:
>>
>> No. XUL has very much been advocated as platform, in years past, by
>> mozilla.org leaders like Brendan Eich and others. Just because you
>> decided otherwise in recent years doesn't make all those apps go away
>> and be paid to be rewritten with some other toolkit. This is a
>> fundamental fact you fail to appreciate.
> I'm not talking about 'XUL'. I'm talking about the reusable build thing
> that we started shipping in 2006 called "XULRunner". That was always an
> experimental build and has never had QA resources.
>
I should have picked a better thread title:
s/XULRunner/Mozilla-based/
> The current plan does not have the main Mozilla project backporting those security fixes.
Speaking of the Mozilla ecosystem, as most of these projects are exposed
to web content I'm afraid of two things:
• more existing Mozilla-based projects will ship unsecure cores;
• the platform won't be as attractive for new projects as before.
Concerning corporate deployments I agree it makes no sense to compete
with Microsoft's 12-year support. But for Mozilla-based projects... I
hope the lack of an LTS branch won't lead to the EOL of the 'XUL' platform.
:kazé
Gijs Kruitbosch
I am a lousy visionary, but, isn't the web the future? Can you give an example
of an app that's written on XULRunner that couldn't possibly be a web app, based
on the current advent of features (FileReader, XHR2 / Cross-domain XHR, WebGL,
Websockets, you name it...)? Wouldn't that (+ better 'app' integration in
Firefox) be a better way to take advantage of the Mozilla platform?
Just look at the Angry Birds Chrome app, which runs just fine on Firefox -
because rather than being built on a chrome-specific thing, it's built using web
tech, which works just fine in other modern browsers. Seems like that would be
better for the end-user, promote choice and innovation on the web (sound
familiar?) etc. etc.
I'm not saying there's no case for native apps, but if you're taking so much
advantage of the web platform that you think XULRunner is your best bet (which
seems to me to be the most plausible reason to pick XULRunner to build your app
on), why don't you actually build it on the web?
Cheers,
Gijs
Joshua Cranmer
> I am a lousy visionary, but, isn't the web the future? Can you give an
> example of an app that's written on XULRunner that couldn't possibly
> be a web app, based on the current advent of features (FileReader,
> XHR2 / Cross-domain XHR, WebGL, Websockets, you name it...)? Wouldn't
> that (+ better 'app' integration in Firefox) be a better way to take
> advantage of the Mozilla platform?
Gijs Kruitbosch
With apologies for plugging my employer: http://www.ebuddy.com/
So, I disagree.
Of course, we have fairly intelligent relay backend servers, but the same can be
done by eg. using flash sockets and connecting to most of these things IM
services directly, building a thin websocket proxy, etc. etc. I wouldn't be
surprised if XMPP had actual extensions to deal with the 'web' usecase that
would allow you to use 'normal' cross-domain XHR, JSONP or similar techniques.
Cheers,
Gijs
Benjamin Smedberg
> I'm not talking about 'XUL'. I'm talking about the reusable build
> thing that we started shipping in 2006 called "XULRunner". That was
> always an experimental build and has never had QA resources.
>
> I want to refresh my memory... when the decision was made to drop
> embedding of gecko, I thought that the response by Mozilla was to tell
> people who wished to use gecko that they should use XULRunner instead.
> Isn't that a tacit commitment to XULRunner as a product?
that it would continue to work even after we removed the "binary stable"
embedding APIs. It would continue to run as it has since 2006. I
certainly never meant to imply that the project would be dedicating new
QA resources or support to it.
--BDS
Ben Bucksch
> On 28/06/2011 19:08 PM, Joshua Cranmer wrote:
>> On 6/28/2011 10:05 AM, Gijs Kruitbosch wrote:
>>> I am a lousy visionary, but, isn't the web the future? Can you give
>>> an example
>>> of an app that's written on XULRunner that couldn't possibly be a
>>> web app,
The problem is not technical, but that I don't want third parties (i.e.
websites) to have my private communications, letters, documents, and
personal notes. I realize that many people today do that (see Facebook),
but even more people do not do that and keep the majority of their data
local only, for good reason. Some of us have read Orwell 1984 and don't
want to live in that world.
That's why we need client software. That's why I need open-source, very
concretely.
Kompozer and text editors might be used to write very private notes.
And no, I definitely don't want websites to access my local filesystem.
Which is what many of the XULRunner apps listed need, including TomTom
HOME 2.
Ben
Robert Kaiser
> But I think the current discussion shows the large community approval
> was on "let's get a new release out every 6 weeks" part of the model,
> not really on the "let's EOL every version except the very latest
> release"
Interestingly that was a part of the proposals right from the beginning.
Robert Kaiser
--
Note that any statements of mine - no matter how passionate - are never
meant to be offensive but very often as food for thought or possible
arguments that we as a community should think about. And most of the
time, I even appreciate irony and fun! :)
Jean-Marc Desperrier
> Jean-Marc Desperrier schrieb:
>> But I think the current discussion shows the large community approval
>> was on "let's get a new release out every 6 weeks" part of the model,
>> not really on the "let's EOL every version except the very latest
>> release"
>
> Interestingly that was a part of the proposals right from the beginning.
That's what I was saying, just that the full consequences were not
understood by many.
Robert Kaiser
> And no, I definitely don't want websites to access my local filesystem.
And I definitely want a way for a locally running web app to be able to
do so if I allow that.
Mike Shaver
> Ben Bucksch schrieb:
>>
>> And no, I definitely don't want websites to access my local filesystem.
>
> And I definitely want a way for a locally running web app to be able to do
> so if I allow that.
We have that for reading, not yet for writing. For
writing-and-saving-for-later, appcache could be pretty close.
https://developer.mozilla.org/en/using_files_from_web_applications
MIke
Gijs Kruitbosch
Wouldn't a website with open-sourced code that stores things � la Sync work for
that purpose?
Of course, it's currently hard to be sure a website runs the exact code they
have in their open repository, but it is similarly hard to do the same with
client-side applications, unless you self-compile everything and only take on
code from authenticated repositories. I would be very surprised if the number of
people sufficiently strict about that is in any way significant compared to the
general population. (although I, too, have my qualms with 'curl
http://example.com/foo.sh | sh' as advertised for eg. PEAR, Node's NPM and
various other tools).
I must say that I find it ironic that, to my knowledge, TomTom HOME is a
proprietary app with no source code visibility. Perhaps you work on it or have
worked on it, but what guarantee do other users have that it doesn't phone home
in a malicious way?
Ultimately (and this is getting to be very off-topic) I don't think the issue of
security can be solved by full inspection, but only by trust and authentication.
Security flaws do exist in open-source tools, it is extremely hard to make
programmer-to-end-user transfers completely secure, etc. etc. And even then,
you're ultimately trusting the programmer. Trust is the base of your (one could
say, any) security model. You trust the open source code, and possibly the
people creating the binaries. Likewise, I can choose to trust a website with my
email, or my documents, or even my money (when was the last time you bought
something online?). You can make different trust decisions than I do, but I
don't understand how using a signed client-side app is so different from using
an SSL-secured website. Technical flaws exist(ed) for both approaches, sure, but
the principle seems the same to me.
Gijs
PS: and yes, I'm aware the example I gave doesn't use SSL. It's something I've
complained about, and we're working on it, but it is sadly not my decision. In
the meantime, it does use client-side encryption to protect against password
sniffing when your data is sent.
Joshua Cranmer
> On 28/06/2011 19:40 PM, Ben Bucksch wrote:
>> The problem is not technical, but that I don't want third parties (i.e.
>> websites) to have my private communications, letters, documents, and
>> personal
>> notes. I realize that many people today do that (see Facebook), but
>> even more
>> people do not do that and keep the majority of their data local only,
>> for good
>> reason. Some of us have read Orwell 1984 and don't want to live in
>> that world.
>>
>> That's why we need client software. That's why I need open-source,
>> very concretely.
>>
>> Kompozer and text editors might be used to write very private notes.
>>
>> And no, I definitely don't want websites to access my local
>> filesystem. Which is
>> what many of the XULRunner apps listed need, including TomTom HOME 2.
>>
>> Ben
>
> work for that purpose?
I don't think you're entirely understanding what I and (I presume) Ben
are complaining about. We don't really *want* the code to need a website
to begin with. Sure, I can use an IRC connection in a webapp by
streaming the data in the server... but I don't want to use a webapp
that does that. It's not the security that I'm concerned about as much
as the desire to not have to rely on the availability of a specific website.
Gijs Kruitbosch
It seemed to me that Ben was talking about privacy and security rather than
availability, but perhaps I misunderstood.
Regarding availability, how would you use instantbird without a network
connection? (for non-network-bound apps, there is HTML5 support for running
offline, of course) And if you're speaking about going out of business, the
exact same happens to client-side applications, right? Without the app (web or
client) being open-source, continuing to use whatever data you have client-side
will be an issue either way.
Gijs
Joshua Cranmer
> Regarding availability, how would you use instantbird without a
> network connection? (for non-network-bound apps, there is HTML5
> support for running offline, of course) And if you're speaking about
> going out of business, the exact same happens to client-side
> applications, right? Without the app (web or client) being
> open-source, continuing to use whatever data you have client-side will
> be an issue either way.
Instantbird would connect to the services, whether or not its own
website is working.
Gijs Kruitbosch
Right, offline cache + manifests take care of that, AIUI.
Mike Shaver
<gijskru...@gmail.com> wrote:
>> Instantbird would connect to the services, whether or not its own website
>> is
>> working.
>
> Right, offline cache + manifests take care of that, AIUI.
Not quite, due to protocol issues, but regardless: please take this
very off-topic part to private mail or similar. Thanks.
Mike
Fabien Cazenave
> I am a lousy visionary, but, isn't the web the future? Can you give an
> example of an app that's written on XULRunner that couldn't possibly be
> a web app, based on the current advent of features (FileReader, XHR2 /
> Cross-domain XHR, WebGL, Websockets, you name it...)? Wouldn't that (+
> better 'app' integration in Firefox) be a better way to take advantage
> of the Mozilla platform?
If I wanted to develop some kind of web app with local storage and
stuff, why would I pick Firefox instead of Chrome in the first place?
And if the future is 100% dedicated to web apps, why are we loosing time
with Gecko, why don't we switch to webkit?
Anyway, I can't really think of any client-slide app that wouldn't
require any web rendering engine nowadays. There are two main approaches
for such desktop apps:
* embed webkit in your desktop app;
* build your app with the Mozilla platform.
If the current plan involves dropping the latter, well... I'll cope with
but I think Mozilla should publish a clear statement about that.
> I'm not saying there's no case for native apps, but if you're taking so
> much advantage of the web platform that you think XULRunner is your best
> bet (which seems to me to be the most plausible reason to pick XULRunner
> to build your app on), why don't you actually build it on the web?
Because there's no decent equivalent of XBL with the web platform.
Because there's no easy way to use overlays with a web app.
Because I might want to use low-level system calls, build my own
platform-specific XPCOM components *and* use a good rendering engine
*and* allow extensibility with a well documented technology.
The Mozilla platform wouldn't be such an awesome toolbox if it hadn't
been web-driven from the very beginning. If we deprecate it because of
the lifecycle policy, I think we should really think of a way to 'port'
such features to the web platform.
:kazé
Boris Zbarsky
> If I wanted to develop some kind of web app with local storage and
> stuff, why would I pick Firefox instead of Chrome in the first place?
Generally because we do something they don't, or do something better
than they do. ;)
> And if the future is 100% dedicated to web apps, why are we loosing time
> with Gecko, why don't we switch to webkit?
Because there are negatives to a monoculture and because some parts of
WebKit are broken by design? There are other reasons too, if this was a
serious question. If it was just rhetorical posturing, on the other
hand....
> The Mozilla platform wouldn't be such an awesome toolbox if it hadn't
> been web-driven from the very beginning. If we deprecate it because of
> the lifecycle policy, I think we should really think of a way to 'port'
> such features to the web platform.
This last is being thought about and worked on, yes.
-Boris
Jesse Ruderman
> The incremental updates will be very large since the changes between full
> releases will be much more than just security fixes.
Splitting updates into smaller chunks doesn't necessarily mean a huge
increase in the total size of the updates over the course of a year.
If we switch to Courgette-compressed updates and fix PGO to be more
deterministic, the 4->5 and 5->6 updates might only add up to slightly
more than a direct 4->6 update.
Robert O'Callahan
Courgette is currently the subject of patent litigation, and I don't know
how we'd fix PGO since that's a Microsoft black box. But even if we did
those things, I'm skeptical of your assertion.
Rob
--
"If we claim to be without sin, we deceive ourselves and the truth is not in
us. If we confess our sins, he is faithful and just and will forgive us our
sins and purify us from all unrighteousness. If we claim we have not sinned,
we make him out to be a liar and his word is not in us." [1 John 1:8-10]
Wes Garland
> Sure, I can use an IRC connection in a webapp by streaming the data in the
> server... but I don't want to use a webapp that does that.
Data point --
I'm a ChatZilla user, and have been for years. I stopped using the
ChatZilla extension and started using it under XULRunner because I was sick
of disconnecting from IRC every time I need to restart my browser.
Wes
--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102
deep64blue
> Dear Mozillians,
>
> a lot has already been said/written about the pros and cons of the new
> lifecycle policy. Nobody doubts it's a good thing for Firefox and the
> web platform in general
Actually lots of us do - from people working in the Enterprise to Add-
on authors to Web Site Developers .....
The issues you go on to discuss are very good examples of the impacts
of this policy.
There needs to be a stable and a rapid branch IMO.
Mark Finkle
> a lot has already been said/written about the pros and cons of the new
> lifecycle policy. Nobody doubts it's a good thing for Firefox and the
> web platform in general, but I'm worried about the consequences for the
> XUL platform (and XULRunner apps in particular).
There is no doubt that the lifecycle policy causes problems for apps
(and devs) built on XULRunner. I am hopeful that a possible LTS
roadmap for Enterprise delopyments would also be leveraged by
XULRunner-based app developers as well. That said, I don't believe
there is a way forward for XULRunner-based applications that want to
stay on a XULRunner version for more than a year. Those developers
would need to manage security fixes themselves, as Benjamin suggested.
IMO, XULRunner app developers should keep an eye on the LTS proposals
and lend their voices to the discussion.
> Does this new lifecycle policy means that all XULRunner-powered apps
> should follow the 6-week pace? That would mean the end of this platform,
> wouldn't it? If this requires to rebuild, test and publish an app every
> 6 week, that won't leave much time to work on the app itself...
If you look at the 6-week pace as more of a point-release system, the
work load is not as monumental as it would appear. It is very hard for
the Mozilla platform to change _that_ significantly in 6 weeks. I have
encouraged XULRunner app devs to try to update the XULRunner backend
as frequently as possible. XULRunner app devs are among the most vocal
about getting new platform features landed and the 6-week cycle only
helps that process. I have also encouraged app devs to move to
strategies that make it easier to avoid bustage from a new XULRunner
releases. The most important of those strategies is avoiding binary
XPCOM bindings and moving to js-ctypes wherever possible.
> I understand an LTS branch for XULRunner (and possibly Firefox) is a
> significant workload, but as many contributors I've been interested in
> the Mozilla project because it's much more than "just a browser". Most
> XULRunner apps don't need the latest Firefox features but they do need
> to get security updates for a significant time period -- say, one year.
Agreed and personally, I am hopeful Mozilla adopts some form of LTS
solution.
> Are there specific plans concerning XULRunner? Or should we consider
> that XULRunner is deprecated?
This comment makes me want to laugh and cry: XULRunner has never been
more vibrant as it it right now! Performance improvements abound, new
XUL, JS and XPCOM features are landing faster than ever.
A few years ago, when I started using XULRunner myself, the cries of
the day were that XULRunner was stagnant. Be careful what you wish
for, you just might get it (and you did in this case).
As with most XULRunner threads/discussions, we all like to blow off
some steam. This thread is no exception. I believe that an LTS
solution will satisfy most if not all of your concerns, as well as the
concerns of others. As to the 6-week cycle, XULRunner app devs will
need to adapt, just as Firefox, Firefox Mobile and Thunderbird app
devs had to adapt. The 6-week cycle is not likely to go away.
Let's turn the 6-week cycle discussion into "How can XULRunner app
devs better leverage the rapid release cycle?". It will probably yield
better outcomes in the end.
Fabien Cazenave
> There is no doubt that the lifecycle policy causes problems for apps
> (and devs) built on XULRunner. I am hopeful that a possible LTS
> roadmap for Enterprise delopyments would also be leveraged by
> XULRunner-based app developers as well.
That's what I'd love to see, for sure!!
A 60-week LTS would be enough for most XULRunner-based app developers, imho.
> IMO, XULRunner app developers should keep an eye on the LTS proposals
> and lend their voices to the discussion.
Will do.
>> Are there specific plans concerning XULRunner? Or should we consider
>> that XULRunner is deprecated?
>
> This comment makes me want to laugh and cry: XULRunner has never been
> more vibrant as it it right now! Performance improvements abound, new
> XUL, JS and XPCOM features are landing faster than ever.
I'm sorry if this sounded harsh, I just wanted to get a clear statement
about XULRunner.
I'm pretty sure that everybody will be fine with the new lifecycle
policy if we can keep the 6-week cycle along with an LTS branch for app
developers and enterprise deployments.
Thanks for your reply!
Georg Maaß
> The QA resources alone, needed to verify the XULRunner app after a major
> XULRunner update, are prohibitive for most apps and teams. They come in
> addition to what I said before.
I stopped my XulRunner Project because I don't have the resources to
find all regressions caused by new XulRunner version.
In the old release cycle I did no tests after an XulRunner update within
the same major release, because the changes were security fixes and
bugfixes only never affecting compatibility, so the test was done, when
choosing the major release as engine. Now I must do it every week,
causing me to do nothing else. There is no more time for development. So
I stopped my project.
XulRunner died with Gecko 2.0.
Robert Kaiser
If you don't have that time, then XULRunner probably was the wrong
technology to build on. You should try doing the same thing with web
technologies instead. The web is alive and will continue to grow to be a
better platform for all kinds of application development.
Georg Maaß
> If you don't have that time, then XULRunner probably was the wrong
> technology to build on. You should try doing the same thing with web
> technologies instead.
No that is exactly the wrong direction.
Robert Kaiser
Why?
Georg Maaß
> Georg Maaß schrieb:
>> Robert Kaiser wrote:
>>> If you don't have that time, then XULRunner probably was the wrong
>>> technology to build on. You should try doing the same thing with web
>>> technologies instead.
>>
>> No that is exactly the wrong direction.
>
> Why?
Because web is outside and application is inside, so web must not have
access to anything inside.
I used XULRunner to build the GUI only for my applications. Web is the
wrong direction, when doing stuff on the local machine.
Georg Maaß
> If I wanted to develop some kind of web app
then use web technology.
> with local storage
then it is not ok, because web must not access anything local.
ya knygar
cookies are here ;)
Robert Kaiser
> Robert Kaiser wrote:
>> Georg Maaß schrieb:
>>> Robert Kaiser wrote:
>>>> If you don't have that time, then XULRunner probably was the wrong
>>>> technology to build on. You should try doing the same thing with web
>>>> technologies instead.
>>>
>>> No that is exactly the wrong direction.
>>
>> Why?
>
> Because web is outside and application is inside, so web must not have
> access to anything inside.
Using HTML instead of XUL for the UI - provided we make HTML capable
enough to do so (which we have not done yet) does not change that equation.
Also, web apps ought to be as well isolated against each other and able
to store things locally than a XUL application is. Note that, just as
above, we still have some of the way there to go still, but also like
above, we have made some progress on that already.
> I used XULRunner to build the GUI only for my applications. Web is the
> wrong direction, when doing stuff on the local machine.
Web apps are just another technology, nobody says they cannot work
locally - in fact, it's well within our plans to make them work offline
and locally just as well as online and called remotely.
Robert Kaiser
> web must not access anything local.
Wrong. If a web app acquires the necessary permissions from the user
(the exact mechanics for that are under discussion in our WebAPI group
and relevant W3C groups), it should be able to do so. And for smaller
bits or database-like access, we already have cookies, localStorage,
indexedDB - and offline app cache for its app files.
Wes Garland
> Web apps are just another technology, nobody says they cannot work locally
> - in fact, it's well within our plans to make them work offline and locally
> just as well as online and called remotely.
>
Microsoft made really good steps in this direction with IE5(?), allowing you
to *.HTA "HyperText Applications". The full HTML development experience was
available to you, along with a privileged security principal, allowing to do
things like change the title bar, application icon, and access ActiveX
controls with the full privileges of the user.
I wrote a backup application for a friend one afternoon that used Windows
Shell ActiveX controls to select files and directories from the GUI; then
the HTA invoked GNU tar running under Cygwin. Except for the DOS window
popping up to run Cygwin, it was virtually indistinguishable from a 'real'
windows app.
Robert Kaiser
> On 29 August 2011 07:34, Robert Kaiser<ka...@kairo.at> wrote:
>
>> Web apps are just another technology, nobody says they cannot work locally
>> - in fact, it's well within our plans to make them work offline and locally
>> just as well as online and called remotely.
>>
>
> Microsoft made really good steps in this direction with IE5(?), allowing you
> to *.HTA "HyperText Applications".
This was just at a time where HTML (and related technologies) wasn't
nearly mature enough to do really useful UI. Even today we are not 100%
there, IMHO, but we are a lot closer for sure.