Organizing our (not so) little community

classic Classic list List threaded Threaded
73 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Re: Organizing our (not so) little community

Tony Polinelli
TLC = Tender Loving Care 



On Wed, Oct 21, 2009 at 5:54 AM, laurent <[hidden email]> wrote:
What is TLC ?

L

Tyler MacLeod a écrit :
Thinking about it, I would love to see some TLC given to the framework.

I believe we already have a great solution to this with haxelib. Utilizing haxelib, we can allow anyone to expand the standard library, and share it with anyone who wishes to use it as well.

-- Tyler MacLeod


On Tue, Oct 20, 2009 at 8:27 AM, Ian Thomas <[hidden email] <mailto:[hidden email]>> wrote:

   +1

   And sorry, Benjamin, if you see your thread as being hijacked into
   another 'forum vs mailing list' but I do think it is important for
   attracting new users.

   On your other notes - I'd _love_ to contribute to the layout of the
   haXe standard library (I have been considering for a while some sort
   of standard cross-platform haXe display API that isn't driven to match
   the Flash API) but I'll never, ever have time. :-( Although for the
   first time in ages I am actually getting to do some proper hands-on
   haXe coding, so you never know...

   Ian

   On Tue, Oct 20, 2009 at 12:21 PM, Martijn Loots <[hidden email]
   <mailto:[hidden email]>> wrote:
   > On Tue, 20 Oct 2009, Heinz Hölzer wrote:
   >
   >> here is already a nice representation of the mailing list,
   >>
   >> http://n2.nabble.com/Haxe-f1354130.html
   >>
   > May I be blunt ?
   >
   >  - I like it. A lot.
   >  - Clean and IMO much better layout than the markmail version
   >  - It should be on haxe.org...
   >  - If on haxe.org <http://haxe.org>, needs a bit of haxe.org
   <http://haxe.org> UI sauce

   >
   > Hope I didn't step on too many toes here. I was a bit too quick
   > reinventing a wheel... I just read armencho's post again, this
   > time eying the very same link... :-/
   >
   > All in all: nice; hope to find this or something very similar
   > on haxe.org <http://haxe.org> soon.

   >
   > Grtz,
   > --
   > -Martijn
   >
   >> Martijn Loots schrieb:
   >>>
   >>> On Tue, 20 Oct 2009, [hidden email]
   <mailto:[hidden email]> wrote:
   >>>
   >>>> On Tue, Oct 20, 2009 at 00:32, Thomas <[hidden email]
   <mailto:[hidden email]>> wrote:
   >>>>>
   >>>>> Also, come guys. Mailing-lists are painful. I prefer forums
   because
   >>>>> it's easier to search for old topics and track discussions.
   >>>>
   >>> [...]
   >>>>
   >>>> In fact, if we want forums so badly, how about using the
   mailing list
   >>>> archives as "model" and present it instead of haXe forum on
   haXe pages
   >>>> ("views"), styled with CSS and with an "internal" web-forms-based
   >>>> message posting GUI? This will be the ultimate tool. You can post
   >>>> to/from the web, or from your POP/SMTP client, and all will
   go to the
   >>>> same place of interest.
   >>>>
   >>> This idea crossed my mind too, several times at least, since the
   >>> birth of the haXe forum. It would be soo nice to see all the
   >>> accumulated mailing list knowledge readily available interactively
   >>> in that very same forum. The current forum is all like haXe
   itself:
   >>> you need that bit of extra effort to appreciate its bare bones
   >>> functionality. A coupling with the mailing archive and a
   simple way
   >>> to edit one's own posts would make it a decent place to look for
   >>> answers (and ask questions that will show up in the mailing list
   >>> too). A central point of haXe contact with access to both worlds:
   >>> the gui oriented forum users and the mailing listers. Speaking for
   >>> myself: I think those worlds in haXe don't have much overlap, so
   >>> this would unite the haXe community immediatly.
   >>>
   >>> I am a mailing lister myself and dislike searching through forums.
   >>>
   >>> If I were a forum user, I'd started a query for everyone right
   >>> now to pinpoint the situation, like "Please answer of of the
   >>> following":
   >>>
   >>>  o I use the mailing list by preference
   >>>
   >>>  o I use the forum by preference
   >>>
   >>>  o I use both forum and mailing list
   >>>
   >>> It would be nice to know for real how the statistics are.
   >>>
   >>> My 2 cents, grtz,
   >>
   >>
   >>
   >
   > --
   > -Martijn    @..@    ( Martijn Loots       -  Hengelo  [NL] )
   > -          (`--')   ( martijn<@>cosix.com <http://cosix.com> -
    www.cosix.com <http://www.cosix.com> )

   > -         ( >__< )  ----------------------------------------
   > -         ^^^  ^^^  (   Netwerken, Security, Open Source   )
   > --
   > haXe - an open source web programming language
   > http://haxe.org
   >

   --
   haXe - an open source web programming language
   http://haxe.org




--
haXe - an open source web programming language
http://haxe.org



--
Tony Polinelli
http://touchmypixel.com

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Organizing our (not so) little community

Laurent Kappler
I see :]
We could reorganise the lib.haxe.org, tags or categories will bring more
clarity to this list
Then it could be extended with possibility to post codes, comments to
open discussions or make branches to libraries

I would like to see more what other people are working on. And maybe
find an easy way to post my code also or exchange way of doing things.
Maybe we are working on the same thing.

For exemple my codes are not finished, but could already be presented
and if someone is working on the same kind of thing we could work
together and exchange ideas.

Laurent

Tony Polinelli a écrit :

> TLC = Tender Loving Care
>
>
>
> On Wed, Oct 21, 2009 at 5:54 AM, laurent <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     What is TLC ?
>
>     L
>
>     Tyler MacLeod a écrit :
>
>         Thinking about it, I would love to see some TLC given to the
>         framework.
>
>         I believe we already have a great solution to this with
>         haxelib. Utilizing haxelib, we can allow anyone to expand the
>         standard library, and share it with anyone who wishes to use
>         it as well.
>
>         -- Tyler MacLeod
>
>
>         On Tue, Oct 20, 2009 at 8:27 AM, Ian Thomas <[hidden email]
>         <mailto:[hidden email]> <mailto:[hidden email]
>         <mailto:[hidden email]>>> wrote:
>
>            +1
>
>            And sorry, Benjamin, if you see your thread as being
>         hijacked into
>            another 'forum vs mailing list' but I do think it is
>         important for
>            attracting new users.
>
>            On your other notes - I'd _love_ to contribute to the
>         layout of the
>            haXe standard library (I have been considering for a while
>         some sort
>            of standard cross-platform haXe display API that isn't
>         driven to match
>            the Flash API) but I'll never, ever have time. :-( Although
>         for the
>            first time in ages I am actually getting to do some proper
>         hands-on
>            haXe coding, so you never know...
>
>            Ian
>
>            On Tue, Oct 20, 2009 at 12:21 PM, Martijn Loots
>         <[hidden email] <mailto:[hidden email]>
>            <mailto:[hidden email] <mailto:[hidden email]>>> wrote:
>            > On Tue, 20 Oct 2009, Heinz Hölzer wrote:
>            >
>            >> here is already a nice representation of the mailing list,
>            >>
>            >> http://n2.nabble.com/Haxe-f1354130.html
>            >>
>            > May I be blunt ?
>            >
>            >  - I like it. A lot.
>            >  - Clean and IMO much better layout than the markmail version
>            >  - It should be on haxe.org...
>            >  - If on haxe.org <http://haxe.org> <http://haxe.org>,
>         needs a bit of haxe.org <http://haxe.org>
>            <http://haxe.org> UI sauce
>
>            >
>            > Hope I didn't step on too many toes here. I was a bit too
>         quick
>            > reinventing a wheel... I just read armencho's post again,
>         this
>            > time eying the very same link... :-/
>            >
>            > All in all: nice; hope to find this or something very similar
>            > on haxe.org <http://haxe.org> <http://haxe.org> soon.
>
>            >
>            > Grtz,
>            > --
>            > -Martijn
>            >
>            >> Martijn Loots schrieb:
>            >>>
>            >>> On Tue, 20 Oct 2009, [hidden email]
>         <mailto:[hidden email]>
>            <mailto:[hidden email] <mailto:[hidden email]>> wrote:
>            >>>
>            >>>> On Tue, Oct 20, 2009 at 00:32, Thomas
>         <[hidden email] <mailto:[hidden email]>
>            <mailto:[hidden email] <mailto:[hidden email]>>> wrote:
>            >>>>>
>            >>>>> Also, come guys. Mailing-lists are painful. I prefer
>         forums
>            because
>            >>>>> it's easier to search for old topics and track
>         discussions.
>            >>>>
>            >>> [...]
>            >>>>
>            >>>> In fact, if we want forums so badly, how about using the
>            mailing list
>            >>>> archives as "model" and present it instead of haXe
>         forum on
>            haXe pages
>            >>>> ("views"), styled with CSS and with an "internal"
>         web-forms-based
>            >>>> message posting GUI? This will be the ultimate tool.
>         You can post
>            >>>> to/from the web, or from your POP/SMTP client, and all
>         will
>            go to the
>            >>>> same place of interest.
>            >>>>
>            >>> This idea crossed my mind too, several times at least,
>         since the
>            >>> birth of the haXe forum. It would be soo nice to see
>         all the
>            >>> accumulated mailing list knowledge readily available
>         interactively
>            >>> in that very same forum. The current forum is all like haXe
>            itself:
>            >>> you need that bit of extra effort to appreciate its
>         bare bones
>            >>> functionality. A coupling with the mailing archive and a
>            simple way
>            >>> to edit one's own posts would make it a decent place to
>         look for
>            >>> answers (and ask questions that will show up in the
>         mailing list
>            >>> too). A central point of haXe contact with access to
>         both worlds:
>            >>> the gui oriented forum users and the mailing listers.
>         Speaking for
>            >>> myself: I think those worlds in haXe don't have much
>         overlap, so
>            >>> this would unite the haXe community immediatly.
>            >>>
>            >>> I am a mailing lister myself and dislike searching
>         through forums.
>            >>>
>            >>> If I were a forum user, I'd started a query for
>         everyone right
>            >>> now to pinpoint the situation, like "Please answer of
>         of the
>            >>> following":
>            >>>
>            >>>  o I use the mailing list by preference
>            >>>
>            >>>  o I use the forum by preference
>            >>>
>            >>>  o I use both forum and mailing list
>            >>>
>            >>> It would be nice to know for real how the statistics are.
>            >>>
>            >>> My 2 cents, grtz,
>            >>
>            >>
>            >>
>            >
>            > --
>            > -Martijn    @..@    ( Martijn Loots       -  Hengelo  [NL] )
>            > -          (`--')   ( martijn<@>cosix.com
>         <http://cosix.com> <http://cosix.com> -
>             www.cosix.com <http://www.cosix.com> <http://www.cosix.com> )
>
>            > -         ( >__< )  ----------------------------------------
>            > -         ^^^  ^^^  (   Netwerken, Security, Open Source   )
>            > --
>            > haXe - an open source web programming language
>            > http://haxe.org
>            >
>
>            --
>            haXe - an open source web programming language
>            http://haxe.org
>
>
>
>
>     --
>     haXe - an open source web programming language
>     http://haxe.org
>
>
>
>
> --
> Tony Polinelli
> http://touchmypixel.com


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Organizing our (not so) little community

Niel Drummond-3
In reply to this post by Benjamin Dasnois
Benjamin Dasnois wrote:
> Please let me re-center my own topic ; this is absolutely not about
> using a mailing-list or a forum. This is about understanding that the
> community is not only who's on the mailing-list (or forum, or
> whatever) but in a variety of place. There were also the two first
> points ;)
>  
I'm quite amazed that not a single response talks about the quite clear
and relevant issues you raised. Quite sad really :-(

Thanks for making those points, I think Nicolas' previous call for
community manager is quite appropriate to solve some of the problems you
mentioned, at least in nominating some more active members to commit a
more authoratitive role. I hope someone can step forward.

We should maybe implement something similar to the AUR in the Arch Linux
distribution, Fedora in redhat, Pear in PHP, whereby some elected peers
oversee and review a selection of haXe applications that make it into a
community repo, which has it's own web site, blogs, activity board and
bug tracker. I think this would fuel a greater interest in the community
to take a more active role in haXe's future - the cream of the crop
could in time become part of std, if it meets Nicolas' standards.

There are some examples, where I have seen good chances fail to reach
the haXe std library for very little reason, maybe because it needs just
a bit more testing - for example Michael Pliskin's flash XML wrapper
(which I love and use); the multitude of JSON parsers... I should not
need to choose - there should be one, one that works well - and it
should be one the community has accepted!

just my thoughts.

- Niel

> On Tue, Oct 20, 2009 at 10:40 AM, Ian Thomas <[hidden email]> wrote:
>  
>> On Mon, Oct 19, 2009 at 11:32 PM, Thomas <[hidden email]> wrote:
>>
>>    
>>> Also, come guys. Mailing-lists are painful. I prefer forums because
>>> it's easier to search for old topics and track discussions.
>>> Unfortunately the forum at haxe.org is total crap. A simple phpbb,
>>> vbulletin or whatever would do a much better job. I also host a forum,
>>> but the code is not quite right yet so I won't propose it.
>>>      
>> This has been raised before. To avoid rehashing - some people prefer
>> forums. Some people prefer mailing lists (myself included). So the
>> solution needs to cater for both tastes.
>>
>> Ian
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>>
>>    
>
>
>
>  


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Organizing our (not so) little community

Owen Durni-2
On Tue, Oct 20, 2009 at 6:18 PM, Niel Drummond
<[hidden email]> wrote:

> Benjamin Dasnois wrote:
>>
>> Please let me re-center my own topic ; this is absolutely not about
>> using a mailing-list or a forum. This is about understanding that the
>> community is not only who's on the mailing-list (or forum, or
>> whatever) but in a variety of place. There were also the two first
>> points ;)
>>
>
> I'm quite amazed that not a single response talks about the quite clear and
> relevant issues you raised. Quite sad really :-(
>
> Thanks for making those points, I think Nicolas' previous call for community
> manager is quite appropriate to solve some of the problems you mentioned, at
> least in nominating some more active members to commit a more authoratitive
> role. I hope someone can step forward.
>
> We should maybe implement something similar to the AUR in the Arch Linux
> distribution, Fedora in redhat, Pear in PHP, whereby some elected peers
> oversee and review a selection of haXe applications that make it into a
> community repo, which has it's own web site, blogs, activity board and bug
> tracker. I think this would fuel a greater interest in the community to take
> a more active role in haXe's future - the cream of the crop could in time
> become part of std, if it meets Nicolas' standards.
>
> There are some examples, where I have seen good chances fail to reach the
> haXe std library for very little reason, maybe because it needs just a bit
> more testing - for example Michael Pliskin's flash XML wrapper (which I love
> and use); the multitude of JSON parsers... I should not need to choose -
> there should be one, one that works well - and it should be one the
> community has accepted!
>
> just my thoughts.
>
> - Niel

I think a major point that has been brought up in previous discussions
of similar issues is that in order to do anything productive a group
of people have to step up and take the first steps. Someone needs to
be willing to take a risk and create a way for content to be managed
in the ways you suggest. They have to be willing to put up a prototype
version and come back to the community for feedback and suggestions at
the risk of being told off. Such a project would almost necessarily
have to start as an "unofficial" entity and hope to earn the support
of the community (thus gaining "authority").

Owen

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Organizing our (not so) little community

Nicolas Cannasse
>> There are some examples, where I have seen good chances fail to reach the
>> haXe std library for very little reason, maybe because it needs just a bit
>> more testing - for example Michael Pliskin's flash XML wrapper (which I love
>> and use); the multitude of JSON parsers... I should not need to choose -
>> there should be one, one that works well - and it should be one the
>> community has accepted!
>>
>> just my thoughts.
>>
>> - Niel
>
> I think a major point that has been brought up in previous discussions
> of similar issues is that in order to do anything productive a group
> of people have to step up and take the first steps. Someone needs to
> be willing to take a risk and create a way for content to be managed
> in the ways you suggest. They have to be willing to put up a prototype
> version and come back to the community for feedback and suggestions at
> the risk of being told off. Such a project would almost necessarily
> have to start as an "unofficial" entity and hope to earn the support
> of the community (thus gaining "authority").

I'm also in favor of a decentralized approach. There is a lot of good
suggestions in Benjamin mail, but I think that many of these can be
performed without the need to setup a formal team of people. If there
are too many concurrent efforts we can organize things further.

The main issue we have as a community is the limited involvement people
can afford. There are many who like haXe, use it a lot, and participate
by contributing code or answering questions on the mailing list. But
going one step further by doing something less "fun" (such as writing
documentation) is the hard part, which is understandable.

If there are people interested in investing more of their personal time
into haXe (and I know some of you already did), because they believe in
the technology and want to push it further and make it become
"mainstream", then we should talk among this small group of people what
are the priorities and how to address them.

This is not a bad calculus to invest time in haXe since the more people
will be interested in haXe the more companies will be looking for haXe
contractor/consultant work and the more you are involved the most likely
you will be able to answer these proposals.

We've already seen several proposals that were not answered by the lack
of people either skilled on the topic or lacking the free time to answer
them. That's as much haXe "success stories" that will not happen.

The other solution is to keep things as-it, which mean things happen
when people feel like doing it. Because we don't really need to become
"mainstream", because the technology works well as it, etc. This is a
possible way, but I agree it lacks momentum.

That's not a complete answer, but already a basis for discussion ;)

Best,
Nicolas

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Organizing our (not so) little community

Armén
In reply to this post by Niel Drummond-3
Instead of talking about the big picture, I will continue talking
about specific issues that in my opinion affect user experience which
covers how new people interested in haXe perceive it (in my opinion of
course). Today: The seach box on the site. It is very unusable and
compared to googling for "searchword site:haxe.org" manually usually
returns 0 results, where Google returns 10 and each of them is quite
relevant. Replacing the search form with Google assisted search is
very easy if one is not Google-paranoid. Many are, I also dislike
plugging Google everywhere, but currently the choice is between
improving search form and replacing it with something much more
functional. How about having Google search in place until a better
search form can be developed in-house? Below is a Google search form
code snippet, copy and paste wherever appropriate in site template:

<form id="search_form" action="http://www.google.com/search"
title="Search this website using Google"><h4 id="search_header">Search
this website:</h4><p id="search_fields"><input id="search_text"
name="q" type="text" /><input type="hidden" name="domains"
value="haxe.org" /><input type="hidden" name="sitesearch"
value="haxe.org" /><input id="search_submit" type="submit"
value="Search" /></p><p id="search_credits"><small>Search powered by
<a href="http://www.google.com">Google</a>.</small></p></form>

What do you think, people? Is it a good practical measure? Of course,
in itself, it is by far not enough to start shifting the picture of
haXe, but is all in the small steps, right?

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Organizing our (not so) little community

Laurent Kappler
In reply to this post by Nicolas Cannasse
Nicolas Cannasse a écrit :

>>> There are some examples, where I have seen good chances fail to
>>> reach the
>>> haXe std library for very little reason, maybe because it needs just
>>> a bit
>>> more testing - for example Michael Pliskin's flash XML wrapper
>>> (which I love
>>> and use); the multitude of JSON parsers... I should not need to
>>> choose -
>>> there should be one, one that works well - and it should be one the
>>> community has accepted!
>>>
>>> just my thoughts.
>>>
>>> - Niel
>>
>> I think a major point that has been brought up in previous discussions
>> of similar issues is that in order to do anything productive a group
>> of people have to step up and take the first steps. Someone needs to
>> be willing to take a risk and create a way for content to be managed
>> in the ways you suggest. They have to be willing to put up a prototype
>> version and come back to the community for feedback and suggestions at
>> the risk of being told off. Such a project would almost necessarily
>> have to start as an "unofficial" entity and hope to earn the support
>> of the community (thus gaining "authority").
>
> I'm also in favor of a decentralized approach. There is a lot of good
> suggestions in Benjamin mail, but I think that many of these can be
> performed without the need to setup a formal team of people. If there
> are too many concurrent efforts we can organize things further.
>
> The main issue we have as a community is the limited involvement
> people can afford. There are many who like haXe, use it a lot, and
> participate by contributing code or answering questions on the mailing
> list. But going one step further by doing something less "fun" (such
> as writing documentation) is the hard part, which is understandable.
>
> If there are people interested in investing more of their personal
> time into haXe (and I know some of you already did), because they
> believe in the technology and want to push it further and make it
> become "mainstream", then we should talk among this small group of
> people what are the priorities and how to address them.
>
> This is not a bad calculus to invest time in haXe since the more
> people will be interested in haXe the more companies will be looking
> for haXe contractor/consultant work and the more you are involved the
> most likely you will be able to answer these proposals.
>
> We've already seen several proposals that were not answered by the
> lack of people either skilled on the topic or lacking the free time to
> answer them. That's as much haXe "success stories" that will not happen.
>
> The other solution is to keep things as-it, which mean things happen
> when people feel like doing it. Because we don't really need to become
> "mainstream", because the technology works well as it, etc. This is a
> possible way, but I agree it lacks momentum.
>
> That's not a complete answer, but already a basis for discussion ;)
>
> Best,
> Nicolas
>
So I think we would need some kind of Github platform for our lib.haxe.org

I would like to know more the working background of haxelib to
forexemple copy it on a server to make tests or at least knowing how to
plug it on a website, and be able to extend it's possibilities.

I have time in juanuary to involve in the community. We could make a
whishlist of fonctionnality we NEED on our Haxe website. It must be a
strong tool, somehow :)

Good morning!
http://www.youtube.com/watch?v=U-oEA1sK374

Laurent

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Organizing our (not so) little community

Heinz Hölzer-2
In reply to this post by Armén
+1

There are so many great open source community tools out there, forums,
bugtracker and so on, that can be used to enhance the community factor,
especially for new users. (  The Forum for example is currently not
usable and lacks so many features )

I think it's great to use Haxe-Created Tools, but only if they are
mature enough.


[hidden email] schrieb:

> Instead of talking about the big picture, I will continue talking
> about specific issues that in my opinion affect user experience which
> covers how new people interested in haXe perceive it (in my opinion of
> course). Today: The seach box on the site. It is very unusable and
> compared to googling for "searchword site:haxe.org" manually usually
> returns 0 results, where Google returns 10 and each of them is quite
> relevant. Replacing the search form with Google assisted search is
> very easy if one is not Google-paranoid. Many are, I also dislike
> plugging Google everywhere, but currently the choice is between
> improving search form and replacing it with something much more
> functional. How about having Google search in place until a better
> search form can be developed in-house? Below is a Google search form
> code snippet, copy and paste wherever appropriate in site template:
>
> <form id="search_form" action="http://www.google.com/search"
> title="Search this website using Google"><h4 id="search_header">Search
> this website:</h4><p id="search_fields"><input id="search_text"
> name="q" type="text" /><input type="hidden" name="domains"
> value="haxe.org" /><input type="hidden" name="sitesearch"
> value="haxe.org" /><input id="search_submit" type="submit"
> value="Search" /></p><p id="search_credits"><small>Search powered by
> <a href="http://www.google.com">Google</a>.</small></p></form>
>
> What do you think, people? Is it a good practical measure? Of course,
> in itself, it is by far not enough to start shifting the picture of
> haXe, but is all in the small steps, right?
>
>  


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Organizing our (not so) little community

Laurent Kappler
In reply to this post by Nicolas Cannasse
Nicolas Cannasse a écrit :

>>> There are some examples, where I have seen good chances fail to
>>> reach the
>>> haXe std library for very little reason, maybe because it needs just
>>> a bit
>>> more testing - for example Michael Pliskin's flash XML wrapper
>>> (which I love
>>> and use); the multitude of JSON parsers... I should not need to
>>> choose -
>>> there should be one, one that works well - and it should be one the
>>> community has accepted!
>>>
>>> just my thoughts.
>>>
>>> - Niel
>>
>> I think a major point that has been brought up in previous discussions
>> of similar issues is that in order to do anything productive a group
>> of people have to step up and take the first steps. Someone needs to
>> be willing to take a risk and create a way for content to be managed
>> in the ways you suggest. They have to be willing to put up a prototype
>> version and come back to the community for feedback and suggestions at
>> the risk of being told off. Such a project would almost necessarily
>> have to start as an "unofficial" entity and hope to earn the support
>> of the community (thus gaining "authority").
>
> I'm also in favor of a decentralized approach. There is a lot of good
> suggestions in Benjamin mail, but I think that many of these can be
> performed without the need to setup a formal team of people. If there
> are too many concurrent efforts we can organize things further.
>
> The main issue we have as a community is the limited involvement
> people can afford. There are many who like haXe, use it a lot, and
> participate by contributing code or answering questions on the mailing
> list. But going one step further by doing something less "fun" (such
> as writing documentation) is the hard part, which is understandable.
>
> If there are people interested in investing more of their personal
> time into haXe (and I know some of you already did), because they
> believe in the technology and want to push it further and make it
> become "mainstream", then we should talk among this small group of
> people what are the priorities and how to address them.
>
> This is not a bad calculus to invest time in haXe since the more
> people will be interested in haXe the more companies will be looking
> for haXe contractor/consultant work and the more you are involved the
> most likely you will be able to answer these proposals.
>
> We've already seen several proposals that were not answered by the
> lack of people either skilled on the topic or lacking the free time to
> answer them. That's as much haXe "success stories" that will not happen.
>
> The other solution is to keep things as-it, which mean things happen
> when people feel like doing it. Because we don't really need to become
> "mainstream", because the technology works well as it, etc. This is a
> possible way, but I agree it lacks momentum.
>
> That's not a complete answer, but already a basis for discussion ;)
>
> Best,
> Nicolas
>
We could also propose some cheap shared hosting for NekoVM, and maybe
some totally free with some conditions if we have a bit of space on each
of our private server.
I think giving 50 Go on a server is quite small but big for the rest of
the world, as 200Mo to 1Go is largely enough for a website. We would
need to define a common application that could be easily reproduced on
someone else server.

Laurent


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Organizing our (not so) little community

Lee Sylvester
In reply to this post by Niel Drummond-3
I think I could help out here, as I'm currently active in producing
tutorial articles and video's which would work well in such an
environment. I'd also like to hear Franco's and Hugh's idea's /
willingness to help out in this arena as they've also contibuted heavily
in this area. It's something I've discussed before with both and so
already thought about.

Lee





Niel Drummond wrote:

> Benjamin Dasnois wrote:
>> Please let me re-center my own topic ; this is absolutely not about
>> using a mailing-list or a forum. This is about understanding that the
>> community is not only who's on the mailing-list (or forum, or
>> whatever) but in a variety of place. There were also the two first
>> points ;)
>>  
> I'm quite amazed that not a single response talks about the quite
> clear and relevant issues you raised. Quite sad really :-(
>
> Thanks for making those points, I think Nicolas' previous call for
> community manager is quite appropriate to solve some of the problems
> you mentioned, at least in nominating some more active members to
> commit a more authoratitive role. I hope someone can step forward.
>
> We should maybe implement something similar to the AUR in the Arch
> Linux distribution, Fedora in redhat, Pear in PHP, whereby some
> elected peers oversee and review a selection of haXe applications that
> make it into a community repo, which has it's own web site, blogs,
> activity board and bug tracker. I think this would fuel a greater
> interest in the community to take a more active role in haXe's future
> - the cream of the crop could in time become part of std, if it meets
> Nicolas' standards.
>
> There are some examples, where I have seen good chances fail to reach
> the haXe std library for very little reason, maybe because it needs
> just a bit more testing - for example Michael Pliskin's flash XML
> wrapper (which I love and use); the multitude of JSON parsers... I
> should not need to choose - there should be one, one that works well -
> and it should be one the community has accepted!
>
> just my thoughts.
>
> - Niel
>> On Tue, Oct 20, 2009 at 10:40 AM, Ian Thomas <[hidden email]> wrote:
>>  
>>> On Mon, Oct 19, 2009 at 11:32 PM, Thomas <[hidden email]> wrote:
>>>
>>>    
>>>> Also, come guys. Mailing-lists are painful. I prefer forums because
>>>> it's easier to search for old topics and track discussions.
>>>> Unfortunately the forum at haxe.org is total crap. A simple phpbb,
>>>> vbulletin or whatever would do a much better job. I also host a forum,
>>>> but the code is not quite right yet so I won't propose it.
>>>>      
>>> This has been raised before. To avoid rehashing - some people prefer
>>> forums. Some people prefer mailing lists (myself included). So the
>>> solution needs to cater for both tastes.
>>>
>>> Ian
>>>
>>> --
>>> haXe - an open source web programming language
>>> http://haxe.org
>>>
>>>    
>>
>>
>>
>>  
>
>


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Organizing our (not so) little community

Franco Ponticelli
On Wed, Oct 21, 2009 at 2:58 PM, Lee McColl Sylvester <[hidden email]> wrote:
I think I could help out here, as I'm currently active in producing tutorial articles and video's which would work well in such an environment. I'd also like to hear Franco's and Hugh's idea's / willingness to help out in this arena as they've also contibuted heavily in this area. It's something I've discussed before with both and so already thought about.

I always try to help when and where I can so I will be available this time too if someone really commits to something ;)

Franco.

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Organizing our (not so) little community

Michiel Crefcoeur
In reply to this post by Benjamin Dasnois
Good point, it is ofcourse a good thing the community is growing but some things really need to change. Here are my thoughts on the subject:

 - Wiki maintenance and Community management
I have some really good experience with using Google Groups. This is the ideal way to manage the community if you ask me. It's feature-complete and ofcourse free. Actually, the ideal way would be Google Wave but that's not yet public. But I expect Groups will integrate nicely with Wave. You can either start a Group or host haXe as a Google Code opensource project that has a Group associated with it. You could use Groups as a replacement for the wiki and the current newsgroup and forum as it is an all-in-one solution. As far as multi-language articles are concerned: the most important thing is that there's one main language that offers all the articles (English). So that if an article is not yet available in, say, Chinese, that page would offer a link to the English version. The main website would then become more like a portal: general information (what is haXe), examples, tutorials, downloads, links to comunity members etc. It would be cool if this website itself would be a showcase of what haXe can do!

 - Standard haXe's framework management
I'm glad to finally have a good excuse to share some ideas I have.
I'm sorry if this gets a bit off-topic and "brainstormy" but I've been struggling with this topic alot lately so here we go:
From my own experience and looking at the introduction of the C++ target together with Neash and NME I've found that the way the framework is currently set up and the way haXelib works have some shortcomings. Don't get me wrong: haXe is by far the best and most flexible of all languages or frameworks but it has so much more potential. I see the current state of haXe as a proof-of-concept for a new way of developing software that's going to be made possible by all the features that haXe offers. I have some thoughts about how to use this potential but I hope it doesn't get too abstract to understand what I mean. :-)
As I've stated here and there on the newsgroup, I've been busy writing haXe libraries for supporting various JavaScript hosts. For instance: I now use haXe for Rhino (using Java objects), ASP, WSH and HTA (using JScript), GLUEscript, JSLibs, JSDB etc the list goes on. The reason why none of it is made public yet (apart from the fact that I'm too busy doing other things) is because I feel that haxelib is not yet suitable for the way I've set up the code. What it would come down to is that I would upload all kinds of libraries, some of which wouldn't even be functional but just serve as a generic layer for other libraries to use. I feel like I'm polluting haxelib that way and not using it in the way that it's meant. So I'm really hesitant to upload the libraries this way. The main cause is the fact that I'm using haXe not just as a cross-platform language but on top of that, also as a cross-host language for which haXe and haXelib were never intended. To give you an example: I do a lot of native object abstraction so that I can write the same higher level code for any JavaScript host that has native objects/API's that offer same functionality. Since all these hosts are using the same target (JS), I can not use inline compiler directives. I solve this by using libraries. This, to me, would also be the preferred way of setting up cross-platform code because this way it's possible to have different community members each write an implementation of a class for a specific target/host (implementing generic interfaces). This way of working would only work if there would be a haxelib replacement that would take all of this into account and make things manageable. Let's call it "haxetypes" for now. This is like haxelib but for classes (types) rather then libraries. Community members can upload interfaces and others can implement these interfaces for various targets and/or hosts. There can even be several implementations of the same class per target/host. Also, an entire native API could be emulated for a different target, like Neash does for Flash for instance. Only now, without having to (know how to) compile with package remapping. And someone else could independently implement the Flash API (or selected parts of it) for another target that requires some specific knowledge about the target.

I think it's about time for a practical example by now:
- I publish an interface on haxetypes: my.guilib.IButton
- I publish a class that implements (this version of) this interface: my.guilib.Button
  If my implementation uses native API's, I tell haxetypes which target(s) and/or host(s) it's for,
  in this case Rhino. In my description I write: "Button using Swing"
- Haxetypes checks if the class correctly implements the interface
- Someone else decides to implement the interface for the Flash target
- Someone else decides to implement the interface, again for Rhino, but using SWT instead of
  Swing for the button

Now, imagine the same principle applied to classes for working with filesystems, databases, window management, protocols...
This way the workload for a cross-target, cross-host library can be effectively distributed throughout the community. The consequence of all this would be that the framework would be totally seperated from the compiler which is a good thing if you ask me.
It would also be a good thing to separate the various compiler targets from the main compiler program. Since I'm already talking about "haxetypes", why not also introduce "haxetargets" where developers can upload target modules for a specific compiler version? :-)
New compiler target modules can be released without there even being any classes implemented for that target. The rest of the community can pick this up. The main benefit for developers is that higher level code can potentially be compiled for ANY target/host as long as this target/host offers the required functionality through native objects and as soon as someone in the community has implemented the required classes.
Haxetypes could be made "smart" so that it can be summoned by the compiler.
Imagine I have this class:

class Example{
  public static function main():void{
    Console.write('hello world');
  }
}

When I compile this class without any further arguments, the compiler enters interactive mode. It "asks" haxetypes which targets the program could be compiled for succesfully depending on whether the target offers implementations of all of the required classes. It can then offer a choise to the user. New compiler targets could at this point be downloaded as a module. After that, It can check for the various supported implementations of the same required class(es) and offer user choises again until finally all the information to successfully compile the class is known. It can download classes that are not already available and it can optionally check for available updates. In the end the compiler can offer to save all the choises to a .hxml file for later use.
So not only can this program be compiled to various targets but also within these targets it can make use of various implementations. For instance: if I choose JavaScript as a target, I could choose for a Console implementation that writes to the Firebug console but I can also choose an implementation that writes to the StdOut stream of the Windows Scripting host or Rhino. The compiler only offers choises that do not conflict. So once I've chosen an implementation that is dependent of a specific host (or hosts), the compiler will only offer implementations that are available for that host.
This makes compiling programs easy and straightforward, I as a user don't need to know anything about what platform(s) it supports or which libraries to use, better yet, a program can be written a year ago for the flash target but in the meantime, the community has worked hard at building all the classes required to compile this program for C++ and if I wait a little longer it will also compile to .NET without having to change the sourcecode and the compiler would tell this! :-)
This kind of distributed development not only unlocks community potential but also offers a great solution for team collaboration, especially when haxetypes could also be hosted on a LAN for non-public types.

I hope that I'm not the only one envisioning this as the future of haXe and I would love to hear your opinions on this. Finally, I would like to note that this way of working can already be achieved with haXe today but my hopes are that at least some of these ideas get implemented as standards in haXe so that it becomes manageable.


2009/10/20 Benjamin Dasnois <[hidden email]>
/*
Please note that this is a long post. There's no pun intended in it.
There's no complaining for the sake of complaining, I'm not targeting
anyone.
*/

Hello,

As haXe, and most important, its community, are growing, I I think
that it could be a good idea to organize the community.

This would have to take into account several points :
 - Wiki maintenance
 - Standard haXe's framework management
 - Community management

Those are the three main concerned points IMHO. Now, let's go deeper
into each one.

Wiki maintenance
==============
As we all know, the wiki is an important thing because it is the first
thing a new-comer sees. But it's also important because it's where
you'll find the "official" documentation. The maintaining the wiki is
difficult ATM because : anyone can edit it, it's multi-languages.

In fact, the main problem is that it's multi-language. So, when we
change something in an English page (and we do that quite often, to
reflect a point discussed on this list for example), it may not be
reflected in other languages (and in fact, there are quite a lot of
chances that it will not be reflected). And to be honest, there are
some languages that haven't seen any change for months. This is a very
important problem because the default website one sees is not the
English one but the localized one which may be really out of sync.

I know we already discussed that, but again, I think it would be good
to have one person in charge for each language. That doesn't mean that
no one else should be editing it. That would just mean that this
person would be a manager, eventually have a team of persons with who
he could work. This is very important and would ease keeping other
languages in sync with the English one.

Standard haXe's framework management
===============================
The Standard Framework is a very important thing too, because as we
all know, even if a language is really good, it's nothing without a
good framework. The thing is the framework is already *big* (don't
forget the code base is even bigger because of multiple targets) and
maybe it should grow.

There are two concerns about the haXe Framework :
  - We need a way to bring new things in the framework, but not
anything should make it to the framework. So, we need some kind of
"proposal" and "moderation" procedures.
  - We need to be able to maintain the framework : accepted proposals
have to be implemented, bugs have to be solved.

Here again, I suggest that we go we the "managers" way. But how to
split it? By targets ? Or by API's parts? (SPOD, JS things, ...)

Community management
===================
Ok seriously, the community is growing, and it's not limited to this
mailing-list. The problem is that we are only aware of people who uses
this mailing-list because we do not organize anything else for the
others. Not having "activity" community oriented also makes some
people leave haXe because they feel like there's nothing happening. I
know I'll hear the "but it's open-source, so things are taking place
everywhere on blogs, websites,... outside of haXe's one" thing. That's
true, but we also need to centralize things. That do not mean that we
need to annihilate things that are outside, but we need to organize
things "inside" too. Look at "modern" languages and frameworks that
made it : they organized things "inside".

In two days, it will be 4 years since haXe development started and in
a little less than a month, that it's been first released to the
public. And how many "community meeting on the web" did we have? One.
ONE. Incredible! Four years, so many people dedicated to haXe, and we
only had ONE meeting online. Why? Because there's no one to organize
things that are community-oriented.

If we want community-driven things, we need community-oriented
activity. And we need someone to organize it.

Please note that I'm going to cross-post this to my blog so that if
some people do not know that the ML is here, they can get in touch.
But I want the discussion to take place here. This is the place where
it has to be.

Regards,

--
DASNOIS Benjamin
http://www.benjamindasnois.com

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Organizing our (not so) little community

jlm@justinfront.net

On 21 Oct 2009, at 16:33, Michiel Crefcoeur wrote:

> upload interfaces and others can implement these interfaces

This would be nice for visuals... graphics, components, video ( which  
worked for html5 and flash!) ... I would like a "view" or "graphic"  
package in the standard library, but I have said this already :)

FEffect already seems to work for tweening, but maybe if I wrote an  
interface/example of how I would like to use/extend it then someone  
can write the code later... sound interesting... is that sort of what  
you mean, we go from how we would want to work and then create  
interfaces that are implemented across all languages later?


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Organizing our (not so) little community

John A. De Goes
In reply to this post by Laurent Kappler

I may be extending (or sponsoring the extending) of haxelib. So anyone  
interested in additional haxelib functionality should contact me.

Regards,

John

On Oct 21, 2009, at 2:28 AM, laurent wrote:

> Nicolas Cannasse a écrit :
>>>> There are some examples, where I have seen good chances fail to  
>>>> reach the
>>>> haXe std library for very little reason, maybe because it needs  
>>>> just a bit
>>>> more testing - for example Michael Pliskin's flash XML wrapper  
>>>> (which I love
>>>> and use); the multitude of JSON parsers... I should not need to  
>>>> choose -
>>>> there should be one, one that works well - and it should be one the
>>>> community has accepted!
>>>>
>>>> just my thoughts.
>>>>
>>>> - Niel
>>>
>>> I think a major point that has been brought up in previous  
>>> discussions
>>> of similar issues is that in order to do anything productive a group
>>> of people have to step up and take the first steps. Someone needs to
>>> be willing to take a risk and create a way for content to be managed
>>> in the ways you suggest. They have to be willing to put up a  
>>> prototype
>>> version and come back to the community for feedback and  
>>> suggestions at
>>> the risk of being told off. Such a project would almost necessarily
>>> have to start as an "unofficial" entity and hope to earn the support
>>> of the community (thus gaining "authority").
>>
>> I'm also in favor of a decentralized approach. There is a lot of  
>> good suggestions in Benjamin mail, but I think that many of these  
>> can be performed without the need to setup a formal team of people.  
>> If there are too many concurrent efforts we can organize things  
>> further.
>>
>> The main issue we have as a community is the limited involvement  
>> people can afford. There are many who like haXe, use it a lot, and  
>> participate by contributing code or answering questions on the  
>> mailing list. But going one step further by doing something less  
>> "fun" (such as writing documentation) is the hard part, which is  
>> understandable.
>>
>> If there are people interested in investing more of their personal  
>> time into haXe (and I know some of you already did), because they  
>> believe in the technology and want to push it further and make it  
>> become "mainstream", then we should talk among this small group of  
>> people what are the priorities and how to address them.
>>
>> This is not a bad calculus to invest time in haXe since the more  
>> people will be interested in haXe the more companies will be  
>> looking for haXe contractor/consultant work and the more you are  
>> involved the most likely you will be able to answer these proposals.
>>
>> We've already seen several proposals that were not answered by the  
>> lack of people either skilled on the topic or lacking the free time  
>> to answer them. That's as much haXe "success stories" that will not  
>> happen.
>>
>> The other solution is to keep things as-it, which mean things  
>> happen when people feel like doing it. Because we don't really need  
>> to become "mainstream", because the technology works well as it,  
>> etc. This is a possible way, but I agree it lacks momentum.
>>
>> That's not a complete answer, but already a basis for discussion ;)
>>
>> Best,
>> Nicolas
>>
> So I think we would need some kind of Github platform for our lib.haxe.org
>
> I would like to know more the working background of haxelib to  
> forexemple copy it on a server to make tests or at least knowing how  
> to plug it on a website, and be able to extend it's possibilities.
>
> I have time in juanuary to involve in the community. We could make a  
> whishlist of fonctionnality we NEED on our Haxe website. It must be  
> a strong tool, somehow :)
>
> Good morning!
> http://www.youtube.com/watch?v=U-oEA1sK374
>
> Laurent
>
> --
> haXe - an open source web programming language
> http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Organizing our (not so) little community

Franco Ponticelli

I may be extending (or sponsoring the extending) of haxelib. So anyone interested in additional haxelib functionality should contact me.

Very glad to here that: password recovery, standardized documentation and associate libs to specific haxe versions would make a big difference with a reasonable effort in my opinion.

Franco


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Organizing our (not so) little community

Lee Sylvester
In reply to this post by Franco Ponticelli
Franco Ponticelli wrote:

> On Wed, Oct 21, 2009 at 2:58 PM, Lee McColl Sylvester
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     I think I could help out here, as I'm currently active in
>     producing tutorial articles and video's which would work well in
>     such an environment. I'd also like to hear Franco's and Hugh's
>     idea's / willingness to help out in this arena as they've also
>     contibuted heavily in this area. It's something I've discussed
>     before with both and so already thought about.
>
>
> I always try to help when and where I can so I will be available this
> time too if someone really commits to something ;)
>
> Franco.

I may sponsor the site hosting and contribute some to the sites
development. Or does anyone here have a suggestion for a CMS?

Lee



--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Organizing our (not so) little community

Laurent Kappler
In reply to this post by John A. De Goes

Maybe some tags/catgories or a search that is more flexible, description
search...
Then a bit more complex: haxelib should enable us to make branches to
libs and/or commit files for approval/deny by the owner. (??)

Then what have been said before about the Haxetypes sounds like candy
mountain :]

Laurent

John A. De Goes a écrit :

>
> I may be extending (or sponsoring the extending) of haxelib. So anyone
> interested in additional haxelib functionality should contact me.
>
> Regards,
>
> John
>
> On Oct 21, 2009, at 2:28 AM, laurent wrote:
>
>> Nicolas Cannasse a écrit :
>>>>> There are some examples, where I have seen good chances fail to
>>>>> reach the
>>>>> haXe std library for very little reason, maybe because it needs
>>>>> just a bit
>>>>> more testing - for example Michael Pliskin's flash XML wrapper
>>>>> (which I love
>>>>> and use); the multitude of JSON parsers... I should not need to
>>>>> choose -
>>>>> there should be one, one that works well - and it should be one the
>>>>> community has accepted!
>>>>>
>>>>> just my thoughts.
>>>>>
>>>>> - Niel
>>>>
>>>> I think a major point that has been brought up in previous discussions
>>>> of similar issues is that in order to do anything productive a group
>>>> of people have to step up and take the first steps. Someone needs to
>>>> be willing to take a risk and create a way for content to be managed
>>>> in the ways you suggest. They have to be willing to put up a prototype
>>>> version and come back to the community for feedback and suggestions at
>>>> the risk of being told off. Such a project would almost necessarily
>>>> have to start as an "unofficial" entity and hope to earn the support
>>>> of the community (thus gaining "authority").
>>>
>>> I'm also in favor of a decentralized approach. There is a lot of
>>> good suggestions in Benjamin mail, but I think that many of these
>>> can be performed without the need to setup a formal team of people.
>>> If there are too many concurrent efforts we can organize things
>>> further.
>>>
>>> The main issue we have as a community is the limited involvement
>>> people can afford. There are many who like haXe, use it a lot, and
>>> participate by contributing code or answering questions on the
>>> mailing list. But going one step further by doing something less
>>> "fun" (such as writing documentation) is the hard part, which is
>>> understandable.
>>>
>>> If there are people interested in investing more of their personal
>>> time into haXe (and I know some of you already did), because they
>>> believe in the technology and want to push it further and make it
>>> become "mainstream", then we should talk among this small group of
>>> people what are the priorities and how to address them.
>>>
>>> This is not a bad calculus to invest time in haXe since the more
>>> people will be interested in haXe the more companies will be looking
>>> for haXe contractor/consultant work and the more you are involved
>>> the most likely you will be able to answer these proposals.
>>>
>>> We've already seen several proposals that were not answered by the
>>> lack of people either skilled on the topic or lacking the free time
>>> to answer them. That's as much haXe "success stories" that will not
>>> happen.
>>>
>>> The other solution is to keep things as-it, which mean things happen
>>> when people feel like doing it. Because we don't really need to
>>> become "mainstream", because the technology works well as it, etc.
>>> This is a possible way, but I agree it lacks momentum.
>>>
>>> That's not a complete answer, but already a basis for discussion ;)
>>>
>>> Best,
>>> Nicolas
>>>
>> So I think we would need some kind of Github platform for our
>> lib.haxe.org
>>
>> I would like to know more the working background of haxelib to
>> forexemple copy it on a server to make tests or at least knowing how
>> to plug it on a website, and be able to extend it's possibilities.
>>
>> I have time in juanuary to involve in the community. We could make a
>> whishlist of fonctionnality we NEED on our Haxe website. It must be a
>> strong tool, somehow :)
>>
>> Good morning!
>> http://www.youtube.com/watch?v=U-oEA1sK374
>>
>> Laurent
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>
>


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Organizing our (not so) little community

Michiel Crefcoeur
In reply to this post by jlm@justinfront.net
Yes that's one aspect of what I mean.
Say you wrote a Flash app that just shows an image and tweens it's size.
This can already be compiled for Neko and C++.
Someone could build the same thing but for JavaScript, nothing new there.
The new thing is, several people could write different implementations of the same logic for different targets, all using the exact same namespaces and classnames.
So someone could work out the tweening part in JS using jQuery while someone else is doing the same thing for Prototype, Dojo or MooTools.
Same goes for displaying the image: you can choose to use an implementation based on an IMG-tag, a DIV with a background-image, a canvas image or even a Flash object, whatever. The code remains the same and the result would be the same (to a certain degree for some purposes).
This is ofcourse a stupid example but you get the point. ;-)
A better example: a cross-platform, cross-target OpenGL API. Your program could be compiled to any platform that supports OpenGL now or in the future without having to use any inline compiler directives. So it could compile to C++, someone could write an API for Flash, someone could wrap WebGL or Google's O3D plug-in, someone could build a wrapper for Rhino (and Java when that target becomes available) and for WSH through ActiveX.

2009/10/21 Justin Lawerance Mills <[hidden email]>

On 21 Oct 2009, at 16:33, Michiel Crefcoeur wrote:

upload interfaces and others can implement these interfaces

This would be nice for visuals... graphics, components, video ( which worked for html5 and flash!) ... I would like a "view" or "graphic" package in the standard library, but I have said this already :)

FEffect already seems to work for tweening, but maybe if I wrote an interface/example of how I would like to use/extend it then someone can write the code later... sound interesting... is that sort of what you mean, we go from how we would want to work and then create interfaces that are implemented across all languages later?


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Organizing our (not so) little community

Ron Wheeler
In reply to this post by Niel Drummond-3
Niel Drummond wrote:

> Benjamin Dasnois wrote:
>> Please let me re-center my own topic ; this is absolutely not about
>> using a mailing-list or a forum. This is about understanding that the
>> community is not only who's on the mailing-list (or forum, or
>> whatever) but in a variety of place. There were also the two first
>> points ;)
>>  
> I'm quite amazed that not a single response talks about the quite
> clear and relevant issues you raised. Quite sad really :-(
>
> Thanks for making those points, I think Nicolas' previous call for
> community manager is quite appropriate to solve some of the problems
> you mentioned, at least in nominating some more active members to
> commit a more authoratitive role. I hope someone can step forward.
>

I am not sure if we are really lacking authority figures or just more
authors.
If people took the time to present the results of their explorations in
short concise tutorials, the web site would get a lot more interesting
and useful.
I do not know if I am falling behind in the editing business since I
only know if someone has added a tutorial if they send a note in the
forum or contact me directly.
I have not edited a new tutorial or article in some time so I am
inclined to think that the authors are not submitting stuff.

I am not sure how the multi-language issue should be resolved. The
automatic translation sounds like a good idea if it can be automated to
the point that all of the languages got updated when a document changed.
A poorly translated chunk of text is a bit more of an incentive to work
on a site than a short page that you know should have more text added.

> We should maybe implement something similar to the AUR in the Arch
> Linux distribution, Fedora in redhat, Pear in PHP, whereby some
> elected peers oversee and review a selection of haXe applications that
> make it into a community repo, which has it's own web site, blogs,
> activity board and bug tracker. I think this would fuel a greater
> interest in the community to take a more active role in haXe's future
> - the cream of the crop could in time become part of std, if it meets
> Nicolas' standards.
>

>
> There are some examples, where I have seen good chances fail to reach
> the haXe std library for very little reason, maybe because it needs
> just a bit more testing - for example Michael Pliskin's flash XML
> wrapper (which I love and use); the multitude of JSON parsers... I
> should not need to choose - there should be one, one that works well -
> and it should be one the community has accepted!
>
> just my thoughts.
>
> - Niel
>> On Tue, Oct 20, 2009 at 10:40 AM, Ian Thomas <[hidden email]> wrote:
>>  
>>> On Mon, Oct 19, 2009 at 11:32 PM, Thomas <[hidden email]> wrote:
>>>
>>>    
>>>> Also, come guys. Mailing-lists are painful. I prefer forums because
>>>> it's easier to search for old topics and track discussions.
>>>> Unfortunately the forum at haxe.org is total crap. A simple phpbb,
>>>> vbulletin or whatever would do a much better job. I also host a forum,
>>>> but the code is not quite right yet so I won't propose it.
>>>>      
>>> This has been raised before. To avoid rehashing - some people prefer
>>> forums. Some people prefer mailing lists (myself included). So the
>>> solution needs to cater for both tastes.
>>>
>>> Ian
>>>
>>> --
>>> haXe - an open source web programming language
>>> http://haxe.org
>>>
>>>    
>>
>>
>>
>>  
>
>


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Organizing our (not so) little community

gershon
Just a small comment, since the language issue has been mentioned here more than once, how about allowing other languages too, mine (Hebrew) for ex.?

On Wed, Oct 21, 2009 at 7:11 PM, Ron Wheeler <[hidden email]> wrote:
Niel Drummond wrote:
Benjamin Dasnois wrote:
Please let me re-center my own topic ; this is absolutely not about
using a mailing-list or a forum. This is about understanding that the
community is not only who's on the mailing-list (or forum, or
whatever) but in a variety of place. There were also the two first
points ;)
 
I'm quite amazed that not a single response talks about the quite clear and relevant issues you raised. Quite sad really :-(

Thanks for making those points, I think Nicolas' previous call for community manager is quite appropriate to solve some of the problems you mentioned, at least in nominating some more active members to commit a more authoratitive role. I hope someone can step forward.


I am not sure if we are really lacking authority figures or just more authors.
If people took the time to present the results of their explorations in short concise tutorials, the web site would get a lot more interesting and useful.
I do not know if I am falling behind in the editing business since I only know if someone has added a tutorial if they send a note in the forum or contact me directly.
I have not edited a new tutorial or article in some time so I am inclined to think that the authors are not submitting stuff.

I am not sure how the multi-language issue should be resolved. The automatic translation sounds like a good idea if it can be automated to the point that all of the languages got updated when a document changed. A poorly translated chunk of text is a bit more of an incentive to work on a site than a short page that you know should have more text added.


We should maybe implement something similar to the AUR in the Arch Linux distribution, Fedora in redhat, Pear in PHP, whereby some elected peers oversee and review a selection of haXe applications that make it into a community repo, which has it's own web site, blogs, activity board and bug tracker. I think this would fuel a greater interest in the community to take a more active role in haXe's future - the cream of the crop could in time become part of std, if it meets Nicolas' standards.



There are some examples, where I have seen good chances fail to reach the haXe std library for very little reason, maybe because it needs just a bit more testing - for example Michael Pliskin's flash XML wrapper (which I love and use); the multitude of JSON parsers... I should not need to choose - there should be one, one that works well - and it should be one the community has accepted!

just my thoughts.

- Niel
On Tue, Oct 20, 2009 at 10:40 AM, Ian Thomas <[hidden email]> wrote:
 
On Mon, Oct 19, 2009 at 11:32 PM, Thomas <[hidden email]> wrote:

 
Also, come guys. Mailing-lists are painful. I prefer forums because
it's easier to search for old topics and track discussions.
Unfortunately the forum at haxe.org is total crap. A simple phpbb,
vbulletin or whatever would do a much better job. I also host a forum,
but the code is not quite right yet so I won't propose it.
     
This has been raised before. To avoid rehashing - some people prefer
forums. Some people prefer mailing lists (myself included). So the
solution needs to cater for both tastes.

Ian

--
haXe - an open source web programming language
http://haxe.org

   



 




--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
1234