Re: it WORKS - Re: [Dynapi-Help] Need some help with IOElement, please.

[Leif W <war...@us...>]

Congratulations!

> ----- Original Message ----- 
> From: "Clemens Eisserer" <lin...@we...>
> To: <dyn...@li...>
> Sent: Monday, October 18, 2004 14:29
> Subject: it WORKS - Re: [Dynapi-Help] Need some help with IOElement,
please.
>
> Not really needed now, however I dont want to stop you if you planed
to
> test with it.

Well, I've been curious for years but if I don't actually decide to do
it at some point, I'll never find the time.  :p  it's just coincidence.

> It would be maybe better to catch Exceptions and write it into the
> logger - should I add this?

I can't speak in specific, but in general, if it helps debug something
to either log on the server, or encapsulate and send to the browser,
then it may be helpful.  I'd probably be very paranoid about what I send
to a browser for security reasons, or else give away too much info about
the server side things.  Probably best to have a generic error message
(or table of messages, "file permissions", "code syntax error", "network
timeout", etc.) sent to browser, and the specific information logged
somewhere reasonably secure on the server.

> PS: I have one question about licensing.
> I want to use DynApi in an half/half project: Code that stands under
GPL
> may use it for free but others should pay a small fee. Is this O.K.
with
> dynapi (not only licensing - but aren't developers angry about that?).
> What I want to do should be quite a small breakthrough in
client/server
> programming, however I may not tell more :-(

Ehh, I tend to ramble abut the GPL, this message could get long.

First I'd suggest reading the GPL and LGPL more thoroughly, maybe look
for a translation if parts are unclear.  I'm not exactly a lawyer, but
tend to be a GPL zealot.  :-)  The DynAPI is LGPL.  I'm not exactly a
lawyer so this may or  may not be legally correct, may be too strict,
but I do think it would be in full compliance with GPL.

Generally it is my understanding that the GPL allows you to do some
things, requires you to do other things, and prevents you from doing
certain things.

* It allows you to take GPL code, make whatever modifications you want,
sell for as much as you can get.  If you have done something unique and
you are in a position to get paid, then you have a right to get what you
can.  :-)

* It requires you to release all your code under the GPL (no
exceptions), to keep the GPL copyright notices in each original and
modified or derivative file, to give full credit to the original authors
at least in each source file (i.e. if there are author's listed in code
comments, just leave them there), to clearly state that it is GPL
software (in the product itself, on the distribution channels, or at the
very least by leaving all the licenses in the code comments intact), and
to provide FREE access to your modified source code upon request
(usually by submitting patches to the main project, or providing web or
FTP access to your modifications).

* It prevents you from calling the derived work your own original work,
prevents you from hiding any modifications you have made and prevents
you from removing the GPL, prevents you from preventing others these
same rights that were freely given to you.

There's also the LGPL, which I've heard called either the Lesser GPL or
the Library GPL, which is what it is conceptually, and what it is
typically used for, respectively.  That allows more flexibility so you
can write a non-free application using the library, yet keep the library
free.

In this case, you obviously would keep your private data and business
logic separate from the API.  If you need a feature in the API, you add
a generic solution which everyone could use, and let others know here,
and people will play with it and break it and fix it and generally have
fun.  :-)  Or perhaps you develop your own non-free API which calls the
unmodified DynAPI, which may be less efficient.  But the same laws of
tainting apply: a coder can't directly submit GPL code after looking at
non-free code, so too you can't look at GPL code and turn and use the
exact same technique and call it non-free.

Maybe it's commonly done but it's just not right and helps no-one.  GPL
coders get around the problem by having two groups: one person becomes
tainted, learns the non-free code, codes nothing, but instead writes
down a specification or a general description which is somewhat
original, then this document is sent to the coding group, which writes
original code.  :-)  You can imagine the extra work involved.

Develop your own API, and think how much longer it will take, and how
much money that costs, it pushes back the project until maybe the client
goes somewhere else.  Now think of the people who did all the work and
didn't even ask for any money and offer it for free to you.

You can simultaneously save time and show appreciation by starting with
GPL software, adding for your needs, and returning the modifications.
:-)  Most clients won't even understand the code or the difference
between licenses,but will be scared and prejudiced against anything
"free".  They won't be able to do it themselves, so they have to pay
someone who knows how to code, to build the site.  It's "Free Software,
not Free Beer", is the common phrase.

Competitive businesses may learn how to do this unique thing you are
doing, and may use it on their site, and eventually you'renot just
unique, but a worldwide internet phenomenon.  ;-)  That is called
progress, which is good, as it can change the world and benefit
everyone, a little at a time.

The valid concern for businesses is to make enough money to offset the
initial development costs before the competition steals the technology,
improves it and undercuts your price.  But if the service or feature
makes website use easier or more efficient or more powerful for the
user, then the user will keep using the website no matter what the
liecense, which could have tremendous positive effect for revenue if
it's ecommerce or subscription driven.  :-)

And so what if someone else does the same thing.  It just means you have
to do it better, which is the essence of competition and progress.  It
is a process that continues for life, not a mountain you climb once and
never slide down.

> Of course I am willed to help dynapi te become even better, fix bugs
> etc. For now I am not very happy with javascript because I come from
the
> java-world but after some time JS should be quite normal for me.

JavaScript is very ugly sometimes.  It's slow (when you use more than a
few dozen layers), buggy, has minimalistic debugging ability (even in
Firefox 1.0PR1 many syntax errors aren't even reported), not always
consistent across browsers (a bloody nightmare), has limitations on what
data it can access (for security reasons), and as you've discovered, can
be a nightmare to debug when talking to server-side applications ("Live
HTTP Headers" plugin may or may not offer some help).

> E.G. I plan to create a table-widget (table with add, get, remove,
....)
> which I also of course plan to contribute back.
> The issue with IOElement and opera, konqueror is also in my interrest
to

Sounds cool!

> be solved, I just say this to tell you that I also want to give
> something back and not only want to use dynapi code. It will be a
> library but not a rival - it has a quite diffenet goal.

I'm not sure what you mean, and you may not wish to describe in any more
detail due to business plans, non-disclosure agreements and business men
with money to give you and lawyers to watch over you.  ;-)

The LGPL definition in the LICENSE file describes the LGPL best.  ;-)
It's difficult to understand without at least 100 lawyer-years of
experience (10 lawyers with 10 years experience each).  ANything outside
of the scope of the GPL or LGPL just makes a nightmare for everyone,
lawyers need to get involed to even understand what anything means,
lawyers tend to be greedy and selfish and may misrepresent either side
as greedy or selfish and create more problems than anything.  A
compromise of some sort of limited restriction would be ideal, where one
business entity could purchase "time" from the project, and the coders
split the money based on their contributions to the code in question,
and could modify GPL or LGPL code, and the company keeps the modified
code for no more than 3 months or 6 months to recover well-earned
development money, and then all modifications manditorily become GPL or
LGPL again.  But setting up such a legal agreement would add so many
lawyer costs to outweigh the benefits, and progress and development
would lag 3-6 months ormore, which is an eternity online.

Leif

> I thought it would be better to ask before coding instead to make
> developers angry.

Always a good idea.  :-)

> Do you think this would be o.k?

I have no idea.  :p  Others have ideas?  I wonder if the Free Software
Foundation has tutorials, FAQs, or other assistive resources to help
people better understand the GPL and LGPL.  It doesn't make much sense
for JavaScript to be proprietary because full source code is always
distributed and always obtainable every time the page is accessed.  :p
The server-side libraries are another matter.  Java can be obfuscated
but can be reverse engineered much easier than other machine-dependent
compiled languages.  So for applets, I consider them potentially
accessible to the public because there's no absolute method to hiding
the code.

Leif