Re: [xul-talk] Because victory wasn't achievable to begin with

[Paul Prescod]

Marc Clifton wrote:

... What does that mean? Why would I want MFC in a cross-platform GUI?


Why would you WANT a cross-platform GUI?  My experiences are probably
different, but the cross-platform applications that I've seen, that try to
unify *anything* except low level code, fail miserable.
I've used some really amazing cross-platform applications: Amazon.com, 
eBay, HoTMaiL, BugZilla, Orkut. The only problem is that these 
applications are limited in the widgets available to them because they 
use a web page development language rather than an application 
development language. Thus, they lack things like proper windows, tree 
widgets, menu bars, rich text areas and so forth. This is what I would 
like XUL to solve.

I frankly can't understand what would be the virtue in XUL _at all_ if 
it were not cross-platform. If I wanted to write Windows GUIs there are 
literally dozens of excellent ways to do that. If you consider XUL a 
competitor to those languages then I can see why you might think it is 
poor. But I don't think that's the point.

...  The GUI's are
non-standard, you can't use the usual tools during development, and the
overall quality of the application suffers.  Sad as it is, if I want to
develop a cross platform application, I'll develop separate apps for each
platform so that users get a familiar-for-their-platform look & feel and the
performance of the app is tailored to the platform.
Great: so you choose the appropriate set of platforms for your users. If 
your choices and theirs are out of sync, you both lose.

 Paul Prescod



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
___
xul-talk mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xul-talk

RE: [xul-talk] Because victory wasn't achievable to begin with

[Charles Goodwin]

Bleh, I quote the original comment I objected to:
"> ... Just because a XUL motor, for example, is GPL, doesn't mean that
applications written on it have to be.

"I disagree.  A GPL is very restrictive.  It only allows applications to
be built that are themselves open source."

I agree with most of your comments below.  But libraries are entirely
different to motors (Interpreters).  Your original comment was wrong.

My distinction is anything but tenuous and quite clearly supported by
the GPL faq.  The _relevant_ bit, that is.  #IfInterpreterIsGPL.

- Charlie

On Sun, 2004-04-11 at 20:57 -0400, Marc Clifton wrote:
> Hi Arron,
> 
> Thank you for shedding light on the matter.
> 
> I think the distinction that Charles is trying to make is tenuous, on the semantics 
> of "based on" vs. "using a".  With regards to MyXaml (my narrow perspective), it's 
> rather confusing:
> 
> 1. The loader (GPL'd) can be used to instantiate your own assemblies.  Can those 
> assemblies be provided as closed source?  I would say yes if I were using Charles' 
> "using" criteria.
>  
> 2. The library (myxaml.dll) is GPL, not LGPL.   Therefore, it fits under the 
> criteria of the link you provided.  Therefore, an application that "uses" (hmm, here 
> we have the same word!) the library must also be open source.
> 
> The only distinction, tenuous at that, is that in the first case, the loader is not 
> a library.  It is an EXE.  But the loader "uses" the library.  Therefore the loader 
> must be GPL'd.  And since, most likely (I can't think of case where this wouldn't 
> happen, except really simple applications), the plug-in assembly ends up "using" the 
> GPL'd library, it also must be GPL'd, unless there is a license exclusion.
> 
> And, of course, it gets even more complicated, because when we come out with a 
> commercial design tool, that needs to include a licensed version of the library that 
> allows you to build closed source applications with it.
> 
> I can see why there's a confusion as to how Linux applications can actually be 
> closed source, because from one perspective, you can view Linux as a giant library.  
> Or at least, at some level, your application is interfacing to functions in a GPL'd 
> library.  I can see why the lawyers are busy.  But a lawyer will always try to prove 
> a case from the point of view of his client, not from the point of view of what is 
> actually right.  To solve the problem, the licensing terms need to spell out the 
> exact conditions for each of the possible use cases.  That's what I will need to do 
> with MyXaml.
> 
> How have the other XUL authors resolved these complexities (or have they)?
> 
> Marc
> 
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Arron Ferguson
> Sent: Sunday, April 11, 2004 8:36 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [xul-talk] Because victory wasn't achievable to begin with
> 
> Both of you,
> 
> Please read this:
> 
> 
> http://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL
> 
> 
> 
> 
> 
> 
> [EMAIL PROTECTED] wrote: -
> 
> To: [EMAIL PROTECTED]
> From: Charles Goodwin <[EMAIL PROTECTED]>
> Sent by: [EMAIL PROTECTED]
> Date: 04/11/2004 05:12PM
> Subject: RE: [xul-talk] Because victory wasn't achievable to begin with
> 
> On Sun, 2004-04-11 at 19:59 -0400, Marc Clifton wrote:
> > Sigh.
> > 
> > >From the GPL:
> > 
> > " 3. You may copy and distribute the Program (or a work based on it
> 
> At what part of that does it apply to developing an XUL application on
> top of an XUL motor? An XUL application is not work based on an XUL
> motor, but work using an XUL motor. If you read the small print you'll
> see there is a difference.
> 
> The GPL license of an XUL motor implies nothing to the license of the
> XUL application in the same way that just because you write an
> application that runs on Linux you do not have to GPL said application.
> 
> Wake up. You're in a land of noo naa. Emailing in your sleep.
> 
> > And frankly, I consider myself a lot more intelligent than most lawyers
> 
> You may be intelligent but you do not understand the GPL. 
> 
> But, hey, you think I'm a moron. Fine... email RMS stating your legal
> opinion on how the GPL affects applications. He'll personally set you
> straight on the matter.
> -- 
> - Charlie
> 
> Charles Goodwin <[EMAIL PROTECTED]>
> Online @ www.charlietech.com
> 
> 
> 
> ---
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> ___
> xul-talk mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/xul-talkNÂHS^ÂÃÅÅXÂÂÅ'ÂÅÃuÂËÃÃÅÃSÂÃ+âÂlÂÅ.)ÃÃÃÂÂÂÅâÅÃÂÃÃyÃÃ
> ÂÃzThmÂÂÂÃÃÂ'^ÅÃÂt!
> ÂÃÅÂ:(ÂÃ!Åâhâ'Â-ÃÂÂÃÃÂ+aÅxÂâÅÂwZâÃÃj[-ÂÃÂÂÃÅvhÂ

RE: [xul-talk] Because victory wasn't achievable to begin with

[Marc Clifton]

Hi Charles,

OK.  In MY particular case, this is relevant:

"However, when the interpreter is extended to provide "bindings" to other
facilities (often, but not necessarily, libraries), the interpreted program
is effectively linked to the facilities it uses through these bindings. So
if these facilities are released under the GPL, the interpreted program that
uses them must be released in a GPL-compatible way. The JNI or Java Native
Interface is an example of such a facility; libraries that are accessed in
this way are linked dynamically with the Java programs that call them. "

If I was too narrow minded to think outside of my particular instance, then
I apologize.

How many XUL motors are mere interpreters, and how may provide bindings?

Marc




---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
___
xul-talk mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xul-talk

RE: [xul-talk] Because victory wasn't achievable to begin with

[Marc Clifton]

Hi Arron,

Thank you for shedding light on the matter.

I think the distinction that Charles is trying to make is tenuous, on the semantics of 
"based on" vs. "using a".  With regards to MyXaml (my narrow perspective), it's rather 
confusing:

1. The loader (GPL'd) can be used to instantiate your own assemblies.  Can those 
assemblies be provided as closed source?  I would say yes if I were using Charles' 
"using" criteria.
 
2. The library (myxaml.dll) is GPL, not LGPL.   Therefore, it fits under the criteria 
of the link you provided.  Therefore, an application that "uses" (hmm, here we have 
the same word!) the library must also be open source.

The only distinction, tenuous at that, is that in the first case, the loader is not a 
library.  It is an EXE.  But the loader "uses" the library.  Therefore the loader must 
be GPL'd.  And since, most likely (I can't think of case where this wouldn't happen, 
except really simple applications), the plug-in assembly ends up "using" the GPL'd 
library, it also must be GPL'd, unless there is a license exclusion.

And, of course, it gets even more complicated, because when we come out with a 
commercial design tool, that needs to include a licensed version of the library that 
allows you to build closed source applications with it.

I can see why there's a confusion as to how Linux applications can actually be closed 
source, because from one perspective, you can view Linux as a giant library.  Or at 
least, at some level, your application is interfacing to functions in a GPL'd library. 
 I can see why the lawyers are busy.  But a lawyer will always try to prove a case 
from the point of view of his client, not from the point of view of what is actually 
right.  To solve the problem, the licensing terms need to spell out the exact 
conditions for each of the possible use cases.  That's what I will need to do with 
MyXaml.

How have the other XUL authors resolved these complexities (or have they)?

Marc

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Arron Ferguson
Sent: Sunday, April 11, 2004 8:36 PM
To: [EMAIL PROTECTED]
Subject: RE: [xul-talk] Because victory wasn't achievable to begin with

Both of you,

Please read this:


http://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL






[EMAIL PROTECTED] wrote: -

To: [EMAIL PROTECTED]
From: Charles Goodwin <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
Date: 04/11/2004 05:12PM
Subject: RE: [xul-talk] Because victory wasn't achievable to begin with

On Sun, 2004-04-11 at 19:59 -0400, Marc Clifton wrote:
> Sigh.
> 
> >From the GPL:
> 
> " 3. You may copy and distribute the Program (or a work based on it

At what part of that does it apply to developing an XUL application on
top of an XUL motor? An XUL application is not work based on an XUL
motor, but work using an XUL motor. If you read the small print you'll
see there is a difference.

The GPL license of an XUL motor implies nothing to the license of the
XUL application in the same way that just because you write an
application that runs on Linux you do not have to GPL said application.

Wake up. You're in a land of noo naa. Emailing in your sleep.

> And frankly, I consider myself a lot more intelligent than most lawyers

You may be intelligent but you do not understand the GPL. 

But, hey, you think I'm a moron. Fine... email RMS stating your legal
opinion on how the GPL affects applications. He'll personally set you
straight on the matter.
-- 
- Charlie

Charles Goodwin <[EMAIL PROTECTED]>
Online @ www.charlietech.com



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
___
xul-talk mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xul-talkNÂHS^ÂÃÅÅXÂÂÅ'ÂÅÃuÂËÃÃÅÃSÂÃ+âÂlÂÅ.)ÃÃÃÂÂÂÅâÅÃÂÃÃyÃÃ
ÂÃzThmÂÂÂÃÃÂ'^ÅÃÂt!
ÂÃÅÂ:(ÂÃ!Åâhâ'Â-ÃÂÂÃÃÂ+aÅxÂâÅÂwZâÃÃj[-ÂÃÂÂÃÅvhÂÅÃkjÃÂÅmÂÃÃvÃ,vw(âÃÂâÃÃÂâZâÃ



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=click
___
xul-talk mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xul-talk

RE: [xul-talk] Because victory wasn't achievable to begin with

[Charles Goodwin]

On Sun, 2004-04-11 at 17:36 -0700, Arron Ferguson wrote:
> Both of you,
> 
> Please read this:
> 
> 
> http://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL

*sigh*

An XUL motor is not a library.  It is a platform, like an OS, for
running applications.

An XUL motor is the equivalent of a JavaVM or Linux.  Programs run on
top of them.

What you _really_ want is this:
http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL

And I'll save you the trouble by quoting the relevant text:
"When the interpreter just interprets a language, the answer is no."

XUL motors interpret XUL applications.  End of.

> 

It's not a flame match.  Somebody is spouting ignorant FUD about the
GPL, stuff RMS and other FS advocates have had to debunk time and time
again.  And you're helping his dellusion by giving out-of-context links.

- Charlie



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
___
xul-talk mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xul-talk

RE: [xul-talk] Because victory wasn't achievable to begin with

[Arron Ferguson]

Both of you,

Please read this:


http://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL






[EMAIL PROTECTED] wrote: -

To: [EMAIL PROTECTED]
From: Charles Goodwin <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
Date: 04/11/2004 05:12PM
Subject: RE: [xul-talk] Because victory wasn't achievable to begin with

On Sun, 2004-04-11 at 19:59 -0400, Marc Clifton wrote:
> Sigh.
> 
> >From the GPL:
> 
> " 3. You may copy and distribute the Program (or a work based on it

At what part of that does it apply to developing an XUL application on
top of an XUL motor? An XUL application is not work based on an XUL
motor, but work using an XUL motor. If you read the small print you'll
see there is a difference.

The GPL license of an XUL motor implies nothing to the license of the
XUL application in the same way that just because you write an
application that runs on Linux you do not have to GPL said application.

Wake up. You're in a land of noo naa. Emailing in your sleep.

> And frankly, I consider myself a lot more intelligent than most lawyers

You may be intelligent but you do not understand the GPL. 

But, hey, you think I'm a moron. Fine... email RMS stating your legal
opinion on how the GPL affects applications. He'll personally set you
straight on the matter.
-- 
- Charlie

Charles Goodwin <[EMAIL PROTECTED]>
Online @ www.charlietech.com



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
___
xul-talk mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xul-talkN¬HS^µéšŠX¬²š'²ŠÞu¼ˆÂâžìSºÚ+‰©l·ž.)îÆÛ­¢¸š–šÞ±éíyÖò
©âzThm¸§°úÞ²'^žÖ§t!¡ñž:(µç!ž‰h‚'¬-櫝ëÞ¯+aŠx®‰ŸºwZ™éíj[-¢Ì¬µéšvh§ŠËkjبžm§ÿÚvÊ,vw(›ö‰ÝxïF¥–‡"w~·òŠ\–'$ÆémjY&j)bž
   
b²Ün–Ö¥’X¬¶Ë(º·~Šàzw­†Ûi³ÿåŠËl²‹«qç讧zßåŠËlþX¬¶)ߣün–Ö¥

RE: [xul-talk] Because victory wasn't achievable to begin with

[Charles Goodwin]

On Sun, 2004-04-11 at 19:59 -0400, Marc Clifton wrote:
> Sigh.
> 
> >From the GPL:
> 
> " 3. You may copy and distribute the Program (or a work based on it

At what part of that does it apply to developing an XUL application on
top of an XUL motor?  An XUL application is not work based on an XUL
motor, but work using an XUL motor.  If you read the small print you'll
see there is a difference.

The GPL license of an XUL motor implies nothing to the license of the
XUL application in the same way that just because you write an
application that runs on Linux you do not have to GPL said application.

Wake up.  You're in a land of noo naa.  Emailing in your sleep.

> And frankly, I consider myself a lot more intelligent than most lawyers

You may be intelligent but you do not understand the GPL.  

But, hey, you think I'm a moron.  Fine... email RMS stating your legal
opinion on how the GPL affects applications.  He'll personally set you
straight on the matter.
-- 
- Charlie

Charles Goodwin <[EMAIL PROTECTED]>
Online @ www.charlietech.com



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
___
xul-talk mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xul-talk

RE: [xul-talk] Because victory wasn't achievable to begin with

[Marc Clifton]

Sigh.

>From the GPL:

" 3. You may copy and distribute the Program (or a work based on it, under
Section 2) in object code or executable form under the terms of Sections 1
and 2 above provided that you also do one of the following: 

a) Accompany it with the complete corresponding machine-readable source
code,"

etc.etc.etc.

Note: OR A WORK BASED ON IT
Note: PROVIDED THAT YOU ALSO:
Note: ACCOMPANY IT WITH THE COMPLETE CORRESPONDING...SOURCE CODE

No modifications necessary.

And frankly, I consider myself a lot more intelligent than most lawyers, so
please don't imply anything about my intelligence in relation to lawyers or,
more importantly, to you.

As far as I'm concerned, this conversation is finished.

Marc



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
___
xul-talk mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xul-talk

RE: [xul-talk] Because victory wasn't achievable to begin with

[Charles Goodwin]

On Sun, 2004-04-11 at 19:40 -0400, Marc Clifton wrote:
> The FAQ says:
> 
> " But if you release the modified version to the public in some way, the GPL
> requires you to make the modified source code available to the program's
> users, under the GPL. "

Are you modifying the XUL motor?  No, you're just using it.

"MODIFIED VERSION".

MySQL AB deliberately spout FUD about the GPL to make people _pay_ for
the licensed version.  It's called 'business'.

Stallman and many, many lawyers (all guys more intelligent than you or
I) have reviewed and refined the GPL into it's current form.  What you
are saying about it is wrong, wrong, wrong.

So please hang this argument by the neck until it is dead, dead, dead.
-- 
- Charlie

Charles Goodwin <[EMAIL PROTECTED]>
Online @ www.charlietech.com



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
___
xul-talk mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xul-talk

RE: [xul-talk] Because victory wasn't achievable to begin with

[Marc Clifton]

Charles wrote:

> ... Please don't comment on this again without bothering to read the GPL
faq available on gnu.org, as you're just embarrassing yourself with these
ignorant comments.

The FAQ says:

" But if you release the modified version to the public in some way, the GPL
requires you to make the modified source code available to the program's
users, under the GPL. "

I would also point you to the information on the MySQL licensing page, which
states:

"The Open Source License allows you to use the software at no charge under
the condition that if you use MySQL in an application you redistribute, the
complete source code for your application must be available and freely
redistributable under reasonable conditions. MySQL AB bases its
interpretation of the GPL on the Free Software Foundation's Frequently Asked
Questions. "

I believe that is the same FAQ you were referring to.

Marc



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
___
xul-talk mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xul-talk

RE: [xul-talk] Because victory wasn't achievable to begin with

[Marc Clifton]

In reply to Arron's comments (umm, in reply to Marc's comments replying to
Arron's comments, replying to Marc's comments--did I get that right???):

> ... I think XUL in itself is not addressing the whole need. Yes, we need
an XML-based UI, yes we need an API to do this in, but we also need a
framework that will support all of the rest of things for that application
as well.

Yes!  I completely concur.

> ... I think that the only thing M$ has brought to the table is the idea
that a XUL needs to be supported in a larger context.

But this is exactly what they are NOT doing.  After making several blog
entries (www.myxaml.com/marcclifton) critical of XAML, the response from the
Avalon architects is that XAML is a specific solution with specific
compromises for a specific set of classes.

MS had the world, but they're blowing it!

> ... I don't know, maybe the next step is an XML programming language that
transparently ties all programming platforms together so that you never know
if it's compiled down to C++, C#, Java, whatever. Definitely a first step
would be to tie XUL/XBL in with Gnome an SVG lib and see where it goes from
there. Then add an XML programming language and ...

Hehe.  The XGUT (Xml Grand Unification Theory). 

However, how do you keep such a thing current so that it supports the next
cool technology?  3D displays.  Surround sound?  The next programming
language?  The burgeoning migration to handheld devices that are growing
more powerful every day?  Webservices and web integration?

And more importantly, since everyone is jumping on the XML bandwagon, how do
you unify all the different schemas that are going to be popping left and
right?  Every vendor, heck, every developer, will shortly have their own
schema/markup to provide an XML solution for their corner of the world.

It's an impossible situation, IMHO, with no solution.  So, what do we do,
when "the whole need" is a constantly moving (and at high speed) target?

Not to sounds like a broken record, but that's why MyXaml is cool.  It isn't
a fixed markup syntax, since it's based on the namespaces, classes, and
property names of whatever assembly you plug into it.  Technically (until MS
breaks reflection or makes obfuscation so that you can't reflect an
assembly), the parser can handle anything written in the .NET framework as
long as it complies with a few parser friendly rules
(http://www.myxaml.com/whitePapers/xamlfriendly.htm). 

To bring this point to clarity, I can add markup that instantiates the
vector graphic engine written by the good people at www.vgdotnet.com
directly in MyXaml.  I'll be demonstrating this in a week or so.

Marc




---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
___
xul-talk mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xul-talk

RE: [xul-talk] Because victory wasn't achievable to begin with

[Charles Goodwin]

On Sun, 2004-04-11 at 19:10 -0400, Marc Clifton wrote:
> In response to Kevin's post:
> 
> > ... Just because a XUL motor, for example, is GPL, doesn't mean that
> applications written on it have to be.
> 
> I disagree.  A GPL is very restrictive.  It only allows applications to be
> built that are themselves open source.

Please don't comment on this again without bothering to read the GPL faq
available on gnu.org, as you're just embarrassing yourself with these
ignorant comments.

For the record, the assertion that 'a GPL XUL motor only allows
applications to be built that are themselves open source' is completely
and utterly incorrect.  The GPL is only viral when in the instance that
applications directly link to the source of ohter GPL software.  This is
explained in the license and in layman's terms in the GPL faq.
-- 
- Charlie

Charles Goodwin <[EMAIL PROTECTED]>
Online @ www.charlietech.com



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
___
xul-talk mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xul-talk

RE: [xul-talk] Because victory wasn't achievable to begin with

[Marc Clifton]

In response to Kevin's post:

> ... Just because a XUL motor, for example, is GPL, doesn't mean that
applications written on it have to be.

I disagree.  A GPL is very restrictive.  It only allows applications to be
built that are themselves open source.

> ... The criteria above has been met by Java since (1997?), so I'm not sure
I understand that sentence...

Oops.  I got carried away.  You are correct.

> ... Aspect oriented programming applies generally to all kinds of
programming (in theory, if not in practice) - as do agile methods, but I
can't see how either are pre-requisites to XUL.

Only in the sense that they are a shift from typical programming practices
(if there is such a thing anymore, but let's assume for the moment that one
"typical" practice is the kind of disaster that you get when using the
Visual Studio wizards).

What AOP and Agile bring to the front isn't necessarily the issues of things
like test first, separation of concerns, etc.  Underlying these are some
very important tenets that hark back to the original 1950's concept of a
"subroutine"--a modular, plug in when you need it, component.  We keep
re-inventing the wheel and calling it something else, it seems.  Underlying
all of these approaches (and underpinning their success or failure) is, as
you said, the "mind-shift required by programmers to understand the
subtleties of true presentation/logic separation".  Even more generally, the
separation of all the different layers.

An XUL application does this implicitly (or almost implicitly).  And for me,
that's a major selling point right there.  But I'm not sure if many people
in the program community are ready for this paradigm shift.

To give you a simple example, I have a friend that I demonstrated the
flexibility of a correctly implemented MVC pattern.  His response was "Wow,
this is cool" but "it's too complicated for simple things".  Of course,
missing the point that simple now becomes complex later.

However, where I'd like to take the http://myxaml.tigris.org project is,
once the designer is in place (a prototype will be ready any day now!) to
aid the programmer in creating MVC patterns using the designer and markup.
I've not seen this done before.  We can also easily move into unit test code
generation (http://aut.tigris.org being my other pet project).

At least, from my perspective, things like XUL/XAML/et al., MVC architecture
(not that it's the end-all of architectures, mind you), and unit testing
will not be truly embraced until there are tools that make easing into (and
out of) these technologies easier for the programmer.

I'll consider it at least a partial victory when Microsoft implements a unit
test generator/engine in VS, along with some useful pattern generation
tools.

Marc




---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
___
xul-talk mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xul-talk

RE: [xul-talk] Because victory wasn't achievable to begin with

[Arron Ferguson]

In reply to Marc's comments replying to Arron's comments,
replying to Marc's comments:


I think really that there are two main reasons why the XUL
Open source/GPL effort is taking so long to bake:

1.) With Open source/GPL projects many people can make projects,
many people can run with a derivative and run with a derivative of
a derivative - case in point Linux ... Debian, Redhat, Lindows, etc.
Efforts and resources scatter, kind of like an easter egg hunt spreads
out. A business is more like paramilitary invading. They go in, destroy,
and get out as quick as possible.

2.) I think XUL in itself is not addressing the whole need. Yes, we
need an XML-based UI, yes we need an API to do this in, but we also
need a framework that will support all of the rest of things for that
application as well. For example, in Java and C# there are tonnes of API
calls to do all sorts of neat stuff like DB connections, sockets,
XML, 2D, 3D, sound, COM, DCOM, CORBA, etc.

XUL and a XUL API do not have this. I think that the only thing M$ has
brought to the table is the idea that a XUL needs to be supported in a
larger context. Programming these days is not the same it was 10 years
ago. Remember using Borland's C++ Builder in Win 3.1? You wrote your
application and hoped that you could find the winsock stack? Sound and
video API calls were unheard of. These days programmers expect (and
rightly so) a rich set of tools to use. Sun really started addressing
this with the Java platform. It has all kinds of APIs. Makes programmers
drool (more than usual) over API calls. Even the C++ programmers got
jealous and at GNU came up with CommonC++ to create a default class
hierarchy that looks suspiciously like the Java world. But then again
the Java class hierarchy looks suspiciously like the Delphi class
hierarchy, and so on ...

Many other efforts have been made (in other platforms) to address
pieces of this but there hasn't been a "final unifier" ...
until now with .NET and XAML ... so long as you play in the windoze 
world. This is the edge that billy boy and the programming monkeys at
M$ have over Mozilla. Unification.

I don't know, maybe the next step is an XML programming language that transparently 
ties all programming platforms together so that you never know if it's compiled down 
to C++, C#, Java, whatever. Definitely a first step would be to tie XUL/XBL in with 
Gnome an SVG lib and see where it goes from there. Then add an XML programming 
language and ...


my 2 cents.


Arron
N¬HS^µéšŠX¬²š'²ŠÞu¼ˆÂâžìSºÚ+‰©l·ž.)îÆÛ­¢¸š–šÞ±éíyÖò
©âzThm¸§°úÞ²'^žÖ§t!¡ñž:(µç!ž‰h‚'¬-櫝ëÞ¯+aŠx®‰ŸºwZ™éíj[-¢Ì¬µéšvh§ŠËkjبžm§ÿÚvÊ,vw(›ö‰ÝxïF¥–‡"w~·òŠ\–'$ÆémjY&j)bž
   
b²Ün–Ö¥’X¬¶Ë(º·~Šàzw­†Ûi³ÿåŠËl²‹«qç讧zßåŠËlþX¬¶)ߣün–Ö¥

RE: [xul-talk] Because victory wasn't achievable to begin with

[Marc Clifton]

In reply to Arron's comments:

> ...Uhh. What are you implying? .NET came up with reflection yes but Java
also came out with reflection 6 years ago. This is nothing new.

> ... Marc, I think you're falling into the same trap that you're suggesting
XAML programmers will fall into in a couple of years and that is that M$
invented reflection. Reflection has been around for 6 years in Java - this
is not anything new.

Oh, sorry!  I didn't mean to imply ignorance of this fact (I have other
ignorances).  I have, however, been a C++ programmer most of my life (6502,
Basic, SAIL, Fortran, Pascal, C++, in that order actually), and my
experience with Java was, admittedly, not very good.  A lot of decisions
were made based on how very different Java-based UI's look compared to what
the customer would be expecting in a Windows app to look and feel like.  I
still get thrown in weird subtle ways when I run a Java client app.  Java
being interpreted for a long time was a problem too.  I was working on
projects that needed good performance, and I didn't want to interface to a
compiled code base simply for the "convenience" of writing the non-critical
stuff in Java.

I think that's sort of the point--we programmers can ooh and ahh over the
coolness of things like reflection in Java, but darn it, the end user
experience has to look acceptable to the end user.  Java apps (like Oracle's
installer) look weird.

I haven't looked at Java in ages and will profess total ignorance--can Java
apps be written in compiled form now interfacing to native Windows controls?

Why did I jump on the C# bandwagon?  Because C# controls are just native
Windows controls, they look and feel like what the user expects, and it's
easy to interface to my existing C++ code base.  And that's what's important
to me, and that's why I haven't moved away from C++/MFC development until
now.  (Again, I looked once at interfacing C++ code with Java, and looked
like an unstable nightmare, but that was years ago).

> .. And that's one of the reasons why I really really respect you and smile
when I see your Web page - you're calling 'em as you see them.

Thanks!  I'll try to live up to the task!

Marc




---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
___
xul-talk mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xul-talk

Re: [xul-talk] Because victory wasn't achievable to begin with

[Kevin Sangeelee]

Most of these points have already been addressed, and since I agreed
with the way they were refuted, I'll only add new comments.

On Sun, 11 Apr 2004, Marc Clifton wrote:

> because it's perfectly clear to me why the XUL community has failed.

I don't see that it has failed.

> Very few people want to touch a GPL project.

That isn't true. For starters, Linux (and of course, GNU) is entirely GPL
and yet is used as a platform for running free, open source, and
proprietary applications.

Just because a XUL motor, for example, is GPL, doesn't mean that
applications written on it have to be.

> The whole concept of declarative markup to instantiate classes, set
> properties, and instantiate collections was basically an exercise in
> futility (or an interesting lab experiment) before .NET and reflection
> came along.

The criteria above has been met by Java since (1997?), so I'm not sure I
understand that sentence, but if I'm correct, then the copyright notice
here (http://www.castor.org/), to give one simple example, shows this not
to be true. This doesn't apply to UI objects, but the principle meets your
criteria above. All the Java XUL motors must use a similar technique.

> Seven, the concept of XUL is beautiful.  But how much education as the XUL
> community done to teach programmers about the flexibility of decoupling
> presentation layer from event process, similar to the MVC pattern?

I fully agree. The mind-shift required by programmers to understand the
subtleties of true presentation/logic separation shouldn't be
underestimated, particularly by advocates of a XUL approach who have
perhaps already become familiar with it. Kind of similar to the shift from
desktop applications to server side web applications. As I recall, that
wasn't a particularly easy transition either.

> The underlying concepts of XUL is closely tied with the MVC pattern,

true

> agile programming, and aspect oriented programming.  If people don't
> understand those concepts, they'll never buy into XUL.

Aspect oriented programming applies generally to all kinds of programming
(in theory, if not in practice) - as do agile methods, but I can't see how
either are pre-requisites to XUL.

My tuppence worth,

Kevin




---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
___
xul-talk mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xul-talk

RE: [xul-talk] Because victory wasn't achievable to begin with

[Marc Clifton]

> ... If there were a single XUL standard then IDE developers would be 
motivated to create forms designers for it?

A standard doesn't imply that something will be used.  It also has to work
with the existing tool base.

> ... What does that mean? Why would I want MFC in a cross-platform GUI?

Why would you WANT a cross-platform GUI?  My experiences are probably
different, but the cross-platform applications that I've seen, that try to
unify *anything* except low level code, fail miserable.  The GUI's are
non-standard, you can't use the usual tools during development, and the
overall quality of the application suffers.  Sad as it is, if I want to
develop a cross platform application, I'll develop separate apps for each
platform so that users get a familiar-for-their-platform look & feel and the
performance of the app is tailored to the platform.

> ... If you want that, you can have it:
http://www.mozilla.org/projects/xpcom/

Hmmm.  I meant interfacing to COM objects written around the "Microsoft"
implementation.  Looking at this website, I don't really see that the
support for that is there.  It seems to be its own custom COM
implementation, but I may have missed something in my brief perusal of the
website.

> ... It does not make sense to conflate "security" with "binary". I won't 
bother addressing this point because it is nonsensical.

OK, maybe I didn't state it right.  I've been told by many people that they
would not ship commercial applications with the markup in human-readable,
easily changeable form.  They want the user interface to their application
"secured", if I may use that term.

> ... And runtime conversion to native code is a lot slower than compile
time conversion but that's the direction Microsoft is going with C#.

>From my understanding, Microsoft's implementation is 1) a serialization of
the form layout, and 2) would normally be used to generate native code at
compile time, not run time.  The fact that it can do run time code
generation does not mean that you would want to do that, especially if
performance is an issue.  It's there if you need dynamic GUI generation.

Even then, once the markup has been created, generating native code and
compiling that, sure, is slower the first time.  But as long as the markup
doesn't change, or changes every so often, then you can use the runtime
generated version, at least until the markup changes again.  I think there's
an advantage in that approach.

> ... ActiveState has built a proprietary application on Mozilla's XUL.

OK.  Still, I've gotten a lot responses regarding concerns over an open
source effort.  Not just licensing, but support, changes, etc.

> ... Mozilla is all C++.

OK.

> ... XBL.

So?  Why would anyone want to write in XBL (or any other markup) directly?
If you want acceptance of a standard, if you want to set the trend, then you
can't just waive your flag and say "I have a standard".  You need tools for
developer acceptance.  A migration path for existing code base.  Products
that work not just equally as well as existing ones, but better.  And that's
really my point--the XUL community needs to get together and get behind a
suite of tools that demonstrate to the developer that there's a viable
alternative to the "Microsoft Way".  Is Mozilla that alternative?  I
personally don't think so.

> ... Do you think that .NET is the only way to do dynamic loading?

No, of course not.  I've implemented several dynamic loading frameworks in
C++, and there's numerous other plug-in architectures out there.

> ... And what is it about .NET reflection that is so much more interesting
than either Java or Active-X reflection?

Good question.  The answer to that is difficult to nail down.  Personally, I
don't see Java as a widely accepted language that meets developer needs
across several key environments.  And I'm not sure Active-X is embraced that
well either.

One of the "problems", trying to get back on track with the XUL issue, is,
for me at least, in the assumption that cross platform development
capability is a good thing.  Frankly, that's not a given for me.  There are
niches, of course, like browsers (which in themselves don't really hold
together as a standard, given the number of "if browser=this else if
browser=that" cases I see in JavaScript).  However, in general, if XUL is
being sold on the idea that it allows cross-platform development, then I
think that's the wrong, erm... platform!

Marc



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
___
xul-talk mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xul-talk

Re: [xul-talk] Opinions of XUL Progress

[George Cao]

Paul,

I agree with your points wholeheartedly.  But I would like to point out 
that "open xul alliance" is probably the wrong place to look for hope 
for advancement in xul.  All the arguments on the usage of the term 
"xul" aside, nobody here seems to be interested in implementing xul.

On the other hand, the mozilla community is very active in discussing, 
experimenting and prototyping various enhancements to xul to make it a 
viable cross platform alternative to xaml.  A group of us have been 
pitching this very idea (using xul+xbl+svg as a response to xaml) to the 
mozilla foundation for a while and the foundation has responded very 
positively (see 
http://www.mozilla.org/events/dev-day-feb-2004/mozilla-futures/title.html 
and http://www.mozillazine.org/articles/article4584.html).  Even an 
ecplise based ide was proposed.

I'll email you off list to share some more details and hopefully 
rekindle your hope for xul.

Best,

George

Paul Prescod wrote:

I am about to unsubscribe from the list. Gerald asked me for my advice 
of where the group should go in comparison to my advice a year ago.

The truth is that at this point I've pretty much lost hope. A year (or 
two or three) ago I hoped that XUL would emerge as the full-app 
equivalent for XHTML. Just as I can now code a web page and have it work 
seamlessly in five or six different browsers (as long as it doesn't go 
too crazy with browser-specific stuff) I hoped that I would be able to 
create a XUL interface and have it work in all of those browsers and 
also on standard open source desktops.

Unfortunately, the Open XUL alliance has done nothing to advance that 
goal. Rather, it has made it less likely by rebranding "XUL" as any XML 
interface language. Any marketing guru will tell you that you never want 
to confuse your market that way. (remember Microsoft's .NET debacle?)

In 2003 my vision was that by the end of 2004 there would be a clear 
movement towards a unified, standardized XUL that would trounce 
Microsoft's Winforms GUI. Instead, Microsoft will have a unified XAML 
and the open source world will have its current chaos. The open source 
world had the XUL idea back in the late 1990s but has waited six years 
for Microsoft to "standardize" it. Now the world will see XAML as a 
Microsoft innovation which will be copied by the open source world. (I 
am confident that we will be forced to standardize to compete)

I'll never understand why we snatched defeat from the jaws of victory.

 Paul Prescod



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
___
xul-talk mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xul-talk
.



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
___
xul-talk mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xul-talk

Re: [xul-talk] Because victory wasn't achievable to begin with

[Arron Ferguson]

In reply to Marc's comments:


[EMAIL PROTECTED] wrote: -

To: <[EMAIL PROTECTED]>
From: "Marc Clifton" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
Date: 04/11/2004 12:50PM
Subject: [xul-talk] Because victory wasn't achievable to begin with


>Fourth, what about licensing? A lot of these XUL parsers are GPL licensed
>(including my own). Very few people want to touch a GPL project. MySQL got
>it right when they offered a license for closed source commercial
>application distribution. How many of the other XUL creators provide that
>option?
This is a good point. Mention closed source to an "average Open source/GPL
programmer and you'll get about the same response as suggesting to a group
of vegans that dinner is at Rockin' Ronnies.


>Sixth, until .NET came along with reflection, 


Uhh. What are you implying? .NET came up with reflection yes but Java also
came out with reflection 6 years ago. This is nothing new.

>The whole concept of declarative markup to
>instantiate classes, set properties, and instantiate collections was
>basically an exercise in futility (or an interesting lab experiment) before
>.NET and reflection came along.


Marc, I think you're falling into the same trap that you're suggesting XAML
programmers will fall into in a couple of years and that is that M$ invented
reflection. Reflection has been around for 6 years in Java - this is not
anything new.



>As the author of MyXaml, I'm trying to show that Microsoft's XAML
>implementation is, well, garbage.
And that's one of the reasons why I really really respect you and smile
when I see your Web page - you're calling 'em as you see them.

;o)

áŠÄ…5ë^™¨¥ŠË)¢{(­ç[ȀL.)îÅ;­¢¸š–ÁkyââžìmºÚ+‰©i­ëž×o 
ڞ'¥F†ÛŠ{­ë"uéíjwBêéÓ¢‹^r薈"zÂÞj¹Þ½êò¶§úè™û§u©žžÖ¥²Ú,ÊË^™§fŠx¬¶¶­Š‰á¶Úý§l¢Çgr‰¿i؝׎ôjYhr'wë(¥ÉbrLn–Ö¥’f¢–)à–+-ÆémjY%ŠËl²‹«qç讧zØm¶›?þX¬¶Ë(º·~Šàzw­þX¬¶ÏåŠËbú?ÆémjY

Re: [xul-talk] Opinions of XUL Progress

[Gerald Bauer]

Hello Paul,

  Thanks for posting your opinion on the XUL saga. 

> I am confident that we will be forced to standardize
> to compete.

  It looks like the W3C is slowly awaking. For
example, the W3C posted a call for participation just
a couple of days ago for a workshop on Web
Applications and Compound Documents. See
http://www.w3.org/2004/04/webapps-cdf-ws/index.html 

  If I may quote from the workshop page:

Web Applications

With the ubiquity of Web browsers and Web document
formats across a range of platforms and devices, many
developers are using the Web as a platform-independent
application environment. Examples of Web applications
include reservation systems, online shopping or
auction sites, games, multimedia applications,
calendars, maps, chat applications, clocks,
interactive design applications, stock tickers,
currency converters and data entry/display systems.

Over the past several years a number of different
technologies have targeted application development on
the Web. However, much of the work in this area has
been proprietary and platform specific.

Web applications typically have some form of
programmatic control, either on the client, on the
server or a combination of both. This workshop
addresses client-side Web applications only. They may
run within the browser, or within another host
application. A Web application is typically downloaded
on demand each time it is "executed", allowing a
developer to update the application for all users when
needed. Web applications are usually smaller than
regular desktop applications, and can have rich
graphical interactive interfaces. 
  

  - Gerald 


---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
___
xul-talk mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xul-talk

Re: [xul-talk] Because victory wasn't achievable to begin with

[Paul Prescod]

Marc Clifton wrote:

...

First, the idea that there is anything to claim victory over regarding the
"pure" XUL concept is a fallacy.  Let's look at XUL from the perspective of
the typical programmer.  Where is the form designer to compete with Visual
Studio? 
If there were a single XUL standard then IDE developers would be 
motivated to create forms designers for it?

... Where is support for MFC? 
What does that mean? Why would I want MFC in a cross-platform GUI?

... Where is the support for COM? 
If you want that, you can have it: http://www.mozilla.org/projects/xpcom/

...
Second, where is the security?  At least Microsoft is addressing the issue
of security with the concept of a binary markup.
It does not make sense to conflate "security" with "binary". I won't 
bother addressing this point because it is nonsensical.

...
Third, what about performance?  Runtime parsing is a lot slower than compile
time GUI generation.
And runtime conversion to native code is a lot slower than compile time 
conversion but that's the direction Microsoft is going with C#. Once 
again, I think that this concern is misplaced. Firefox and Thunderbird 
show that XUL interfaces are quite performant.

Fourth, what about licensing?  A lot of these XUL parsers are GPL licensed
(including my own).  Very few people want to touch a GPL project.  MySQL got
it right when they offered a license for closed source commercial
application distribution.  How many of the other XUL creators provide that
option?
ActiveState has built a proprietary application on Mozilla's XUL.

Fifth, where are the XUL parsers that work with C++?  Of the list that I've
seen Gerald post, I haven't seen one!  Am I missing something here?  Is the
XUL community like an ostrich sticking its head in the sand on the Java
beach, ignoring every other important language out there?
Mozilla is all C++.

Sixth, until .NET came along with reflection, writing an XUL parser was a
PITA.  Any custom COM object, plug in, component, heck, even any custom
classes you wrote in your application would need some form of customization
in the parser to extend it. 
XBL.

...
I could probably go on.  I'll stop now.  I'd be very interested to read the
feedback, because if anything, it's clear to me that XUL could never have
achieved victory, whether Microsoft was around or not.  It took .NET's
reflection to make it truly useable.
You haven't made that case at all. I don't see any logic in that 
argument at all. Do you think that .NET is the only way to do dynamic 
loading? And what is it about .NET reflection that is so much more 
interesting than either Java or Active-X reflection?

 Paul Prescod



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
___
xul-talk mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xul-talk

[xul-talk] Because victory wasn't achievable to begin with

[Marc Clifton]

In reply to Paul's comment:

"I'll never understand why we snatched defeat from the jaws of victory."

I'd like to throw in my 2c worth.  I'm a bit frank about my opinions and I
suspect that I might offend a few people and demonstrate my ignorance of XUL
at large at the same time.  After reading Paul's post, I guess I got a bit
riled up, because it's perfectly clear to me why the XUL community has
failed.

First, the idea that there is anything to claim victory over regarding the
"pure" XUL concept is a fallacy.  Let's look at XUL from the perspective of
the typical programmer.  Where is the form designer to compete with Visual
Studio?  Where is support for MFC?  Where is the support for COM?  Where is
the support for plug-in's?  And that's just the questions from the
perspective of a Window's developer.  I'm sure the Mac developer has very
similar questions.  As a developer myself, I wouldn't have wanted to touch
XUL with a 10 foot pole, lacking these essential requirements.

Second, where is the security?  At least Microsoft is addressing the issue
of security with the concept of a binary markup.  Many of my users have
brought up concerns about the security of markup, when the customer can
easily change the markup.  Not a good situation.  Sure, for the open-source
egghead community, that's what it's all about.  For professionals trying to
earn a living, privacy and security is a key issue.

Third, what about performance?  Runtime parsing is a lot slower than compile
time GUI generation.

Fourth, what about licensing?  A lot of these XUL parsers are GPL licensed
(including my own).  Very few people want to touch a GPL project.  MySQL got
it right when they offered a license for closed source commercial
application distribution.  How many of the other XUL creators provide that
option?

Fifth, where are the XUL parsers that work with C++?  Of the list that I've
seen Gerald post, I haven't seen one!  Am I missing something here?  Is the
XUL community like an ostrich sticking its head in the sand on the Java
beach, ignoring every other important language out there?

Sixth, until .NET came along with reflection, writing an XUL parser was a
PITA.  Any custom COM object, plug in, component, heck, even any custom
classes you wrote in your application would need some form of customization
in the parser to extend it.  The whole concept of declarative markup to
instantiate classes, set properties, and instantiate collections was
basically an exercise in futility (or an interesting lab experiment) before
.NET and reflection came along.

Seven, the concept of XUL is beautiful.  But how much education as the XUL
community done to teach programmers about the flexibility of decoupling
presentation layer from event process, similar to the MVC pattern?  Try
googling on "MVC" or "Model-View-Controller".  It's a desert waste land out
there, and the few references (except for the Sun Java site), get it wrong!
The underlying concepts of XUL is closely tied with the MVC pattern, agile
programming, and aspect oriented programming.  If people don't understand
those concepts, they'll never buy into XUL.

I could probably go on.  I'll stop now.  I'd be very interested to read the
feedback, because if anything, it's clear to me that XUL could never have
achieved victory, whether Microsoft was around or not.  It took .NET's
reflection to make it truly useable.  If you don't agree with that argument,
then I can only fall back on the fact that the XUL community itself shot
itself in the foot for the last 10 years.

As the author of MyXaml, I'm trying to show that Microsoft's XAML
implementation is, well, garbage.  One of the key tenets of the MyXaml
implementation is that the tags are generic and based on the underlying DOM
of the classes that it instantiates.  In my opinion, the concept of markup
in conjunction with .NET's reflection is an incredibly powerful plug-in
manager, component mediator, and general purpose instantiator.  That's where
I wish the XUL community had been moving for the last 10 years.

OK, I'll really shut up now.

Marc




---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
___
xul-talk mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xul-talk

[xul-talk] Because victory wasn't achievable to begin with

[Marc Clifton]

In reply to Paul's comment:

"I'll never understand why we snatched defeat from the jaws of victory."

I'd like to throw in my 2c worth.  I'm a bit frank about my opinions and I
suspect that I might offend a few people and demonstrate my ignorance of XUL
at large at the same time.  After reading Paul's post, I guess I got a bit
riled up, because it's perfectly clear to me why the XUL community has
failed.

First, the idea that there is anything to claim victory over regarding the
"pure" XUL concept is a fallacy.  Let's look at XUL from the perspective of
the typical programmer.  Where is the form designer to compete with Visual
Studio?  Where is support for MFC?  Where is the support for COM?  Where is
the support for plug-in's?  And that's just the questions from the
perspective of a Window's developer.  I'm sure the Mac developer has very
similar questions.  As a developer myself, I wouldn't have wanted to touch
XUL with a 10 foot pole, lacking these essential requirements.

Second, where is the security?  At least Microsoft is addressing the issue
of security with the concept of a binary markup.  Many of my users have
brought up concerns about the security of markup, when the customer can
easily change the markup.  Not a good situation.  Sure, for the open-source
egghead community, that's what it's all about.  For professionals trying to
earn a living, privacy and security is a key issue.

Third, what about performance?  Runtime parsing is a lot slower than compile
time GUI generation.

Fourth, what about licensing?  A lot of these XUL parsers are GPL licensed
(including my own).  Very few people want to touch a GPL project.  MySQL got
it right when they offered a license for closed source commercial
application distribution.  How many of the other XUL creators provide that
option?

Fifth, where are the XUL parsers that work with C++?  Of the list that I've
seen Gerald post, I haven't seen one!  Am I missing something here?  Is the
XUL community like an ostrich sticking its head in the sand on the Java
beach, ignoring every other important language out there?

Sixth, until .NET came along with reflection, writing an XUL parser was a
PITA.  Any custom COM object, plug in, component, heck, even any custom
classes you wrote in your application would need some form of customization
in the parser to extend it.  The whole concept of declarative markup to
instantiate classes, set properties, and instantiate collections was
basically an exercise in futility (or an interesting lab experiment) before
.NET and reflection came along.

Seven, the concept of XUL is beautiful.  But how much education as the XUL
community done to teach programmers about the flexibility of decoupling
presentation layer from event process, similar to the MVC pattern?  Try
googling on "MVC" or "Model-View-Controller".  It's a desert waste land out
there, and the few references (except for the Sun Java site), get it wrong!
The underlying concepts of XUL is closely tied with the MVC pattern, agile
programming, and aspect oriented programming.  If people don't understand
those concepts, they'll never buy into XUL.

I could probably go on.  I'll stop now.  I'd be very interested to read the
feedback, because if anything, it's clear to me that XUL could never have
achieved victory, whether Microsoft was around or not.  It took .NET's
reflection to make it truly useable.  If you don't agree with that argument,
then I can only fall back on the fact that the XUL community itself shot
itself in the foot for the last 10 years.

As the author of MyXaml, I'm trying to show that Microsoft's XAML
implementation is, well, garbage.  One of the key tenets of the MyXaml
implementation is that the tags are generic and based on the underlying DOM
of the classes that it instantiates.  In my opinion, the concept of markup
in conjunction with .NET's reflection is an incredibly powerful plug-in
manager, component mediator, and general purpose instantiator.  That's where
I wish the XUL community had been moving for the last 10 years.

OK, I'll really shut up now.

Marc




---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
___
xul-talk mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xul-talk

[xul-talk] Opinions of XUL Progress

[Paul Prescod]

I am about to unsubscribe from the list. Gerald asked me for my advice 
of where the group should go in comparison to my advice a year ago.

The truth is that at this point I've pretty much lost hope. A year (or 
two or three) ago I hoped that XUL would emerge as the full-app 
equivalent for XHTML. Just as I can now code a web page and have it work 
seamlessly in five or six different browsers (as long as it doesn't go 
too crazy with browser-specific stuff) I hoped that I would be able to 
create a XUL interface and have it work in all of those browsers and 
also on standard open source desktops.

Unfortunately, the Open XUL alliance has done nothing to advance that 
goal. Rather, it has made it less likely by rebranding "XUL" as any XML 
interface language. Any marketing guru will tell you that you never want 
to confuse your market that way. (remember Microsoft's .NET debacle?)

In 2003 my vision was that by the end of 2004 there would be a clear 
movement towards a unified, standardized XUL that would trounce 
Microsoft's Winforms GUI. Instead, Microsoft will have a unified XAML 
and the open source world will have its current chaos. The open source 
world had the XUL idea back in the late 1990s but has waited six years 
for Microsoft to "standardize" it. Now the world will see XAML as a 
Microsoft innovation which will be copied by the open source world. (I 
am confident that we will be forced to standardize to compete)

I'll never understand why we snatched defeat from the jaws of victory.

 Paul Prescod



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
___
xul-talk mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xul-talk