A call for a new name

12 views
Skip to first unread message

franky...@gmail.com

unread,
Oct 29, 2008, 6:25:43 PM10/29/08
to wxJavaScript
I'm in the middle of reworking wxJavaScript to make it work without
wxWidgets. wxWidgets will still be used to create gui's, but it will
be possible to use wxJavaScript without the wxWidgets dependencies. I
started this because wxWidgets 3.0 doesn't support wxODBC anymore. So
I went looking for a replacement, and found POCO at
http://pocoproject.org/poco/info/index.html . POCO has also a better
solution for sockets, http, mail, ...

That's why I'm looking for a new name for this project. I've already
received some suggestions, but maybe you have a better name. And maybe
someone can come up with a logo for the project.

Franky.

PS. The next release will still have a DB module. Only when wxWidgets
releases version 3.0 it will be deprecated. The IO module stays
available too.

mariuz

unread,
Oct 30, 2008, 6:40:30 AM10/30/08
to wxJavaScript


On Oct 30, 12:25 am, franky.br...@gmail.com wrote:
> I'm in the middle of reworking wxJavaScript to make it work without
> wxWidgets. wxWidgets will still be used to create gui's, but it will
> be possible to use wxJavaScript without the wxWidgets dependencies. I
> started this because wxWidgets 3.0 doesn't support wxODBC anymore. So
> I went looking for a replacement, and found POCO athttp://pocoproject.org/poco/info/index.html. POCO has also a better
> solution for sockets, http, mail, ...
>
> That's why I'm looking for a new name for this project. I've already
> received some suggestions, but maybe you have a better name. And maybe
> someone can come up with a logo for the project.
>
> Franky.
>
> PS. The next release will still have a DB module. Only when wxWidgets
> releases version 3.0 it will be deprecated. The IO module stays
> available too.

Maybe FlameScript

I met with one of the mozilla evangelists and they told me that
flamerobin is an good name for an project
so think is a good start for an name.

Fabien Meghazi

unread,
Oct 30, 2008, 10:31:45 AM10/30/08
to wxjava...@googlegroups.com
> I'm in the middle of reworking wxJavaScript to make it work without
> wxWidgets. wxWidgets will still be used to create gui's, but it will
> be possible to use wxJavaScript without the wxWidgets dependencies. I
> started this because wxWidgets 3.0 doesn't support wxODBC anymore. So
> I went looking for a replacement, and found POCO at
> http://pocoproject.org/poco/info/index.html . POCO has also a better
> solution for sockets, http, mail, ...

That's excellent news !

I recently contacted this list because I was searching a server side
javascript web solution.
I recently searched all the related project around (1) and I must say
that nothing convinced me.
(1) http://en.wikipedia.org/wiki/Server-side_JavaScript

So I gave back the server side JavaScript idea and my next project
will be coded in python or ruby on server side.
But I don't despair one day there will be a good solution for this,
and I've the feeling it could be your project.

It seems to me that you are about to take your project to another
direction and that might be the time to think deeper before you move
on (if not already done)

My thought is that if you do it well, you will undoubtedly lead your
project to something really big. By big I don't mean bloated, I mean
something that will attract interest of a LOT of people. Nowadays,
javascript is the most popular language if you consider those millions
of websites using it, and all the products embedding a js engine. I'm
sure a *LOT* of people would like to have an all purpose development
platform (cross platform) using the javascript language. They just
don't know it yet :-)

Imagine something that allows you to make system scripts on POSIX
where you used to code in bash/python/perl/whatever.
Imagine the same solution allows you to create web applications on
POSIX or windows.
Imagine you could use the same solution for creating games, gui
applications, frontends, anything you want in a cross platform way.

Yes, you named it. It's yet another developement platform.

The good news is that you don't have to do all this work. All you need
is a good base system well designed. Then some communication around
your project and people will start to be interested. I'm sure that you
won't have to wait to long before some bindings pops out everywhere.
Look at python. I've choosed python over ruby just because of the
large amount of bindings and libraries available. If your project gets
popular, people will make bindings for it : opengl, sdl, wxWidgets,
Qt, Cairo, ffmpeg, imagemagick, portaudio, ... Everything we need in
an all purpose development platform.


In order to make this happen, you shall meet the following :

1) use a last generation javascript engine (tracemonkey, V8 or
squirrelfish extreme, ... whatever)

2) create a good base api which is not bloated but stay consistent,
powerful and easy to use/remember (very important)

3) make this api in a way that keeps the spirit of javascript coding.
Use of event driven/callbacks where relevant. Optionaly use object as
function arguments where it make sense (if possible). Eg: If you don't
want to see that in your code anymore : do_my_stuff("name", false,
false, true, 8, 12, false, "A");
you shall be able to use :

do_my_stuff( { tile : "name", force : true, age : 8, count : 12,
letter : "A" } );

What is great about javascript is that it is highly dynamic. An api
that would not use this feature of the js language would fail.

4) define guidelines about how to make bindings/extensions (this is
very important in order to avoid a mess and keep consistency )


You may say I'm a dreamer, but I'm not the only one. ;-)

Seriously, I don't have C++ knowledge and my low level coding
experience is too far away so I don't know if what I say is possible.
I don't know either how the integration of POCO would be done with the
javascript engine.
But if the POCO methods/objects can be used as a kind of namespace in
the javascript engine, then the api in javascript could just be a
wrapper to the POCO namespace. And writing the api in javascript would
be better because the base system won't change.
If POCO's api is clean enough, there might even be no need for a wrapped api.


Of course I don't know if your goal is to put your project under spotlight.
If not, then forget what I said and quickly press the delete button.
If yes, then I would like to know what you think about this.


PS: sorry for my bad english.

PS2: Yes, I drank a lot of coffee today !

--
Fabien Meghazi

Website: http://www.amigrave.com
Email: a...@amigrave.com
IM: amig...@gmail.com

whoiste...@hotmail.com

unread,
Nov 5, 2008, 7:00:28 AM11/5/08
to wxJavaScript
Franky,

I think that the best thing about wxjs (and your biggest strength) is
it's adaptability; what this means is that it takes the best from
what's available, be it spidermonkey (javascript interpreting), apache
(secure server), wx (mature cross-platform library), memcache, curl,
etc... and assimilate all of them into it.

This should be reflected in the new identity, because I believe this
will continue as long as you're on the project.

Just comparing with other alternatives likes AppJet and POW; wxjs is
still better in my opinion because of this assimilation ability.
AppJet just posted a self-host version which means it is now what wxjs
has always been; they do have some items which are better, like better
community, and actual hosting service. POW is interesting because it
can self host and able to debug with "firebug". These are all
features which wxjs has the potential to expand into, if given a
bigger community, which I think is your goal when you say you're
looking for a new name.

So, maybe you need a name which in general captures the idea that wxjs
can and will expand.

Also, since you're open source, you can use something like
OpenSomething, seems pretty popular to say something is open source
these days.

By the way, as you know I use you wxODBC module, and obviously I would
like to see continue support of it. I hope you can continue to keep
depreciating modules, or have a replacement, as long as there is
continuity I am happy. I worry that there will be a new version and I
can't use it because of some module that is depreciated.

Some quick examples:
BorgScript
FlexiScript
OpenScript
Expanscript
ModuScript

Regards
Terence

On Oct 30, 6:25 am, franky.br...@gmail.com wrote:
> I'm in the middle of reworking wxJavaScript to make it work without
> wxWidgets. wxWidgets will still be used to create gui's, but it will
> be possible to use wxJavaScript without the wxWidgets dependencies. I
> started this because wxWidgets 3.0 doesn't support wxODBC anymore. So
> I went looking for a replacement, and found POCO athttp://pocoproject.org/poco/info/index.html. POCO has also a better

USCode

unread,
Nov 7, 2008, 2:26:52 PM11/7/08
to wxJavaScript
Hi Franky,
As I already sent you via email;
How about a general name that would be more appropriate to it's more
general nature?

How about "GLUE" or "GLUEscript" ?

i.e.

General (or Glue)
Language
Using (or Utilizing)
ECMAScript

As it is a general-purpose language that provides an easy way to
"glue" together many other libraries easily to build any kind of
application.
You have a nice competitor here to the other major scripting languages
but with many advantages over the others, please keep up the good
work!
Thanks,
Brian

whoiste...@hotmail.com

unread,
Nov 10, 2008, 10:41:07 AM11/10/08
to wxJavaScript
I like GlueScript

whoiste...@hotmail.com

unread,
Nov 10, 2008, 10:44:47 AM11/10/08
to wxJavaScript
How about

Gluing
Libraries
Using
ECMAScript

Or

Great
Libraries
Utilitizing
ECMAScript

On Nov 8, 3:26 am, USCode <bgschmidt_...@yahoo.com> wrote:

troels knak-nielsen

unread,
Nov 10, 2008, 10:49:26 AM11/10/08
to wxjava...@googlegroups.com
MonkeyScript? (It *is* based on SpiderMonkey, after all)

--
troels

Reply all
Reply to author
Forward
0 new messages