Thread: [Dynapi-Dev] Counting so far

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

For:
Me
Dann
Barre
Doug
Gortsilas
Against:
Pascal

I can't decide what Jordi is. And if anyone wants to move to the against or
be added to any of the 2 let me know

8an

this seems quite ridiculous, but for what it's worth add me to the against.
i'd rather see x-browser bugs fixed first.

i really doubt that the current object model is what is causing instability,
if you can actually prove that perhaps i'll change sides.

> -----Original Message-----
> From: dyn...@li...
> [mailto:dyn...@li...]On Behalf Of Eytan
> Heidingsfeld
> Sent: 30 January 2001 16:13
> To: Dynapi-Dev
> Subject: [Dynapi-Dev] Counting so far
>
>
> For:
> Me
> Dann
> Barre
> Doug
> Gortsilas
> Against:
> Pascal
>
> I can't decide what Jordi is. And if anyone wants to move to the
> against or
> be added to any of the 2 let me know
>
> 8an
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev

 For:
 Me
 Dann
 Barre
 Doug
 Gortsilas

 Against:
 Pascal
Cameron

You can count all you want, but that serves no useful purpose to this
project other than to detract from the DynAPI.

If you want to build your own library, go ahead.  But Dan created the
DynAPI 2 and we are here to help make the DynAPI 2 a viable api.  If
you don't like it, don't use it.

-- 
// Robert Rainwater

On 1/30/2001, 11:25:01 AM EST, Eytan wrote about "[Dynapi-Dev] Counting so far":

>  For:
>  Me
>  Dann
>  Barre
>  Doug
>  Gortsilas

>  Against:
>  Pascal
> Cameron

> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev

----------------------
DynAPI Snapshots: http://dynapi.sourceforge.net/snapshot/
DynAPI Homepage: http://dynapi.sourceforge.net/

I agree completely.

Besides, Pascal himself has a different distribution of the
DynAPI, why don't you guys do the same? That way you can try out
your ideas and concepts at your leisure.

NunoF

-----Original Message-----
From: dyn...@li...
[mailto:dyn...@li...]On Behalf Of Robert
Rainwater
Sent: terca-feira, 30 de Janeiro de 2001 16:33
To: DynAPI Development List
Subject: Re[2]: [Dynapi-Dev] Counting so far

You can count all you want, but that serves no useful purpose to this
project other than to detract from the DynAPI.

If you want to build your own library, go ahead.  But Dan created the
DynAPI 2 and we are here to help make the DynAPI 2 a viable api.  If
you don't like it, don't use it.

-- 
// Robert Rainwater

Hold on,

I'm not against Pascal's ideas either, so my judgement is hung ! Not me... the
judgement, okay ?

CU,
 Dann

I am very against. Eytan, can you please send me this SuperClass object
please?

Is this a case of win or loose?
Eytan against Pascal??

We've had all the theoretical explanations, every one has been able to
demonstrate their in-depth knowledge and their preference regarding object
model, a discussion is great, but lets get back to work now! Instead of
breaking up the group with petty rivalries.

There are different things to be done, and several groups of people showing
interest in them:

* NS6 debugging, starting at the core of the API, later the widgets.
several people showed interest here.

* Mac debugging, now we have some Mac users, their efforts should not be
shunned.

* Memory management, coupled with the basic structure of the API, OOP etc.
This is what Doug and Eytan showed a lot of interest in, why not set up a
test case, of a very basic API, so stability and memory use can be tested.
If there is an improvement, the benefits should be clear. Also this would
give people like me a chance to see what you are actually talking about, a
lot of technical abbreviations make the whole thing a bit confusing.

* User interfaces, several projects going on here, either web based or not,
Dan's Java Builder, or Henrik Våglins DynBuilder.
These projects might or might not take of, we won't know if we don't try.

* Documentation, Robert and Pascal have put in a great effort here, keep up
the good work.

* Designer access, here I mean access for the normal javascript coder, who
wants to check out the DynAPI, without necessarily knowing the code inside
out.
That's the part I'm working on as much as I can, supplying examples, and
answering user questions as I can. These people will become our future
user-base, and the step to DynAPI use should be as low as possible.
See what happened to PHP in 5 years time, after year one they were where we
are now.

* Widget development, if the widget model has stabilized, it would be great
to see some functional, error free, and logical widgets, we need window
management, timeline, etc + a whole bank of pathanim add-ons to do all kinds
of animation. There's a lot out there already which I'm trying to group as
it is.

* Group moderation, this is what Dann Pascal and Robert do (among others)
and is basically taking the decisions.
Someone has to do that, otherwise everybody would be overwriting each others
code in CVS 'cause they didn't like the "style".
There are a few things that could be improved here to, as I feel a lot of
knowledge gets lost as it's simply ignored, but it should come from two
sides, submitters should be able to accept at face value that their "great"
fix, wasn't accepted, but the moderator should at least acknowledge having
seen the submission, if not giving a reason for every line of code they
reject/accept.
Also, we should try to restrict any bug reports to something which can be
reproduced, I mean, if you say, mouse events don't work in a nested layer
containing an image, while the parent is moving across the screen, you
expect the moderator to spend time reproducing that specific example. If it
helps I'll open a public ftp account, with the latest snapshot preinstalled,
so bug examples can be uploaded, and are all tested against the latest
snapshot.

Anyway, I think we have to much work to do, to waste time counting...

Cheers,
Richard Bennett

ma...@ri...
www.richardinfo.com
(Everything running on, and ported to the 19/12/2000 snapshot of DynAPI2)

----- Original Message -----
From: "Eytan Heidingsfeld" <ey...@tr...>
To: "Dynapi-Dev" <dyn...@li...>
Sent: Tuesday, January 30, 2001 5:12 PM
Subject: [Dynapi-Dev] Counting so far

> For:
> Me
> Dann
> Barre
> Doug
> Gortsilas
> Against:
> Pascal
>
> I can't decide what Jordi is. And if anyone wants to move to the against
or
> be added to any of the 2 let me know
>
> 8an
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev
> ____________________________________________________________
> Get your free domain name and domain-based e-mail from
> Namezero.com. New!  Namezero Plus domains now available.
> Find out more at: http://www.namezero.com
>

Voice of reason reaching us.

thanks.

Pascal Bestebroer
pa...@dy...
http://www.dynamic-core.net

> -----Oorspronkelijk bericht-----
> Van: dyn...@li...
> [mailto:dyn...@li...]Namens Richard Bennett
> Verzonden: dinsdag 30 januari 2001 18:36
> Aan: dyn...@li...
> Onderwerp: Re: [Dynapi-Dev] Counting so far
>
>
> Is this a case of win or loose?
> Eytan against Pascal??
>
> We've had all the theoretical explanations, every one has been able to
> demonstrate their in-depth knowledge and their preference regarding object
> model, a discussion is great, but lets get back to work now! Instead of
> breaking up the group with petty rivalries.
>
> There are different things to be done, and several groups of
> people showing
> interest in them:
>
> * NS6 debugging, starting at the core of the API, later the widgets.
> several people showed interest here.
>
> * Mac debugging, now we have some Mac users, their efforts should not be
> shunned.
>
> * Memory management, coupled with the basic structure of the API, OOP etc.
> This is what Doug and Eytan showed a lot of interest in, why not set up a
> test case, of a very basic API, so stability and memory use can be tested.
> If there is an improvement, the benefits should be clear. Also this would
> give people like me a chance to see what you are actually talking about, a
> lot of technical abbreviations make the whole thing a bit confusing.
>
> * User interfaces, several projects going on here, either web
> based or not,
> Dan's Java Builder, or Henrik Våglins DynBuilder.
> These projects might or might not take of, we won't know if we don't try.
>
> * Documentation, Robert and Pascal have put in a great effort
> here, keep up
> the good work.
>
> * Designer access, here I mean access for the normal javascript coder, who
> wants to check out the DynAPI, without necessarily knowing the code inside
> out.
> That's the part I'm working on as much as I can, supplying examples, and
> answering user questions as I can. These people will become our future
> user-base, and the step to DynAPI use should be as low as possible.
> See what happened to PHP in 5 years time, after year one they
> were where we
> are now.
>
> * Widget development, if the widget model has stabilized, it
> would be great
> to see some functional, error free, and logical widgets, we need window
> management, timeline, etc + a whole bank of pathanim add-ons to
> do all kinds
> of animation. There's a lot out there already which I'm trying to group as
> it is.
>
> * Group moderation, this is what Dann Pascal and Robert do (among others)
> and is basically taking the decisions.
> Someone has to do that, otherwise everybody would be overwriting
> each others
> code in CVS 'cause they didn't like the "style".
> There are a few things that could be improved here to, as I feel a lot of
> knowledge gets lost as it's simply ignored, but it should come from two
> sides, submitters should be able to accept at face value that
> their "great"
> fix, wasn't accepted, but the moderator should at least acknowledge having
> seen the submission, if not giving a reason for every line of code they
> reject/accept.
> Also, we should try to restrict any bug reports to something which can be
> reproduced, I mean, if you say, mouse events don't work in a nested layer
> containing an image, while the parent is moving across the screen, you
> expect the moderator to spend time reproducing that specific
> example. If it
> helps I'll open a public ftp account, with the latest snapshot
> preinstalled,
> so bug examples can be uploaded, and are all tested against the latest
> snapshot.
>
> Anyway, I think we have to much work to do, to waste time counting...
>
> Cheers,
> Richard Bennett
>
> ma...@ri...
> www.richardinfo.com
> (Everything running on, and ported to the 19/12/2000 snapshot of DynAPI2)

> * Group moderation, this is what Dann Pascal and Robert do (among others)
> and is basically taking the decisions.
> Someone has to do that, otherwise everybody would be overwriting
> each others
> code in CVS 'cause they didn't like the "style".
> There are a few things that could be improved here to, as I feel a lot of
> knowledge gets lost as it's simply ignored, but it should come from two
> sides, submitters should be able to accept at face value that
> their "great"
> fix, wasn't accepted, but the moderator should at least acknowledge having
> seen the submission, if not giving a reason for every line of code they
> reject/accept.

I'm a bit curious on that front. I've submitted some patches for NS6, anyone
on the developers must know about them, I've dropped hints about them being
put into CVS numerous times. They never have been put into CVS, and I've
never received any explanation why not. Fair enough if my fixes aren't good
enough, if that's why they aren't going in tell me, perhaps I can improve
them. But it is frustrating not knowing, and it's not a great incentive to
carry on trying to contribute.

I'm sure this goes for anyone who's trying to help out, if your help is
completely ignored then you stop helping. mind you if your efforts are
completely shot down, perhaps you stop helping too. so be nice when you tell
people they their code is shite ;-)

cameron.

I haven't touched the DynAPI code for the last couple of months (only one or
two small things done) Robert has been implement bug-fixes alot and I guess
some of those he never got around to.

Patches on sourceforge will be looked at, as long as there not closed there
not checked out...

Pascal Bestebroer
pa...@dy...
http://www.dynamic-core.net

> -----Oorspronkelijk bericht-----
> Van: dyn...@li...
> [mailto:dyn...@li...]Namens Cameron Hart
> Verzonden: dinsdag 30 januari 2001 19:51
> Aan: dyn...@li...
> Onderwerp: RE: [Dynapi-Dev] Counting so far
>
>
> > * Group moderation, this is what Dann Pascal and Robert do
> (among others)
> > and is basically taking the decisions.
> > Someone has to do that, otherwise everybody would be overwriting
> > each others
> > code in CVS 'cause they didn't like the "style".
> > There are a few things that could be improved here to, as I
> feel a lot of
> > knowledge gets lost as it's simply ignored, but it should come from two
> > sides, submitters should be able to accept at face value that
> > their "great"
> > fix, wasn't accepted, but the moderator should at least
> acknowledge having
> > seen the submission, if not giving a reason for every line of code they
> > reject/accept.
>
> I'm a bit curious on that front. I've submitted some patches for
> NS6, anyone
> on the developers must know about them, I've dropped hints about
> them being
> put into CVS numerous times. They never have been put into CVS, and I've
> never received any explanation why not. Fair enough if my fixes
> aren't good
> enough, if that's why they aren't going in tell me, perhaps I can improve
> them. But it is frustrating not knowing, and it's not a great incentive to
> carry on trying to contribute.
>
> I'm sure this goes for anyone who's trying to help out, if your help is
> completely ignored then you stop helping. mind you if your efforts are
> completely shot down, perhaps you stop helping too. so be nice
> when you tell
> people they their code is shite ;-)
>
> cameron.
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>

> I'm a bit curious on that front. I've submitted some patches for NS6, anyone
> on the developers must know about them, I've dropped hints about them being
> put into CVS numerous times. They never have been put into CVS, and I've
> never received any explanation why not. Fair enough if my fixes aren't good
> enough, if that's why they aren't going in tell me, perhaps I can improve
> them. But it is frustrating not knowing, and it's not a great incentive to
> carry on trying to contribute.

I have no problem including many of the NS 6 patches.  However, I'm
not very experienced in NS 6, so I hesitate to make any changes.
Especially since its hard to tell of others have tested the patches
themselves.

Maybe we just need a better process for patch submission.  But unless
others in the group are actively testing the patches, then I don't
want to make changes, especially NS 6 or Mac patches.
-- 
// Robert Rainwater
----------------------
DynAPI Snapshots: http://dynapi.sourceforge.net/snapshot/
DynAPI Homepage: http://dynapi.sourceforge.net/

I think Richard tested them.

Fair enough though if you're not sure about them. Perhaps if there are 
to be people moderating additions to the CVS you should assign a browser 
to each moderator (or are you the only moderator Robert?). If someone 
(or more than one person) is experience with NS6 or Mac IE5 then they 
should check and okay any changes.

The only testing I've done is with the DynAPI examples, and with the 
site I'm working on. It's better to test with something complicated I 
think, as it tends to show up faults in the code, the examples are a bit 
too simple for this. Widgets are good for highlighting problems I've found.

Some of the developers must know a bit about NS6 though as there is a 
lot of support in the API already, although some of it is a bit out of 
date (for example, NS6 final supports innerHTML).

Robert Rainwater wrote:

> 
>> I'm a bit curious on that front. I've submitted some patches for NS6, anyone
>> on the developers must know about them, I've dropped hints about them being
>> put into CVS numerous times. They never have been put into CVS, and I've
>> never received any explanation why not. Fair enough if my fixes aren't good
>> enough, if that's why they aren't going in tell me, perhaps I can improve
>> them. But it is frustrating not knowing, and it's not a great incentive to
>> carry on trying to contribute.
> 
> 
> I have no problem including many of the NS 6 patches.  However, I'm
> not very experienced in NS 6, so I hesitate to make any changes.
> Especially since its hard to tell of others have tested the patches
> themselves.
> 
> Maybe we just need a better process for patch submission.  But unless
> others in the group are actively testing the patches, then I don't
> want to make changes, especially NS 6 or Mac patches.