On 8/19/06, Youness Alaoui <[EMAIL PROTECTED]> wrote:
On Sat, Aug 19, 2006 at 03:48:06AM +0200, Ole Andr? Vadla Ravn?s wrote:
> On 8/19/06, Philippe Khalaf <[EMAIL PROTECTED]> wrote:
> >
> >On Sat, 19 Aug 2006 00:21:15 +0200
> >Harry Vennik <[EMAIL PROTECTED]> wrote:
> >
> >> Hi all,
> >>
> >> Finally I found some time to document some of my ideas in more detail.
> >The
> >> result is this new draft. Quite a lot changed since the previous one,
> >and it
> >> will change again in the next drafts (at least on those places where it
> >just
> >> contains some vague suggestions). But I think things already are a lot
> >better
> >> and more clear now.
> >>
> >> Any feedback is appreciated!
> >>
> >> Harry
> >
> >I've read your draft. It's good and I think can be followed
> >successfully, but there are a few issues.
> >
> >First of all, you don't need to talk to Farsight directly. Telepathy
> >has a stream-engine component that takes care of Farsight. You only
> >need to request StreamedMedia channels and you are good to go. So no
> >bindings required there.
> >
> >Before going to the next point I want to say that I think any proposals
> >to write our own cross-platform toolkit are absurd. That is a HUGE
> >project by itself and involves a ridiculous amount of time to
> >undertake. I am sorry to say that no one in this project has the skill,
> >time or experience to do it.
> >
> >The last serious issue is with the choice of using TCL. TK is
> >getting dumped, so might as well dump TCL. Why? Your proposal involves
> >writing a lot of bindings! Bindings for D-Bus and bindings for
> >wxWindows. These will take a lot of time and energy to complete.
> >Imagine all the time saved working with something that already has
> >those bindings. If you guys want to keep the high level language thing
> >going for aMSN, then we need to think of Python. It has good D-Bus
> >bindings as well as wxWindows bindings. It is better and more popular
> >than TCL. It seems like the logical and correct solution to take.
> >People who don't know it can learn it, new developers who already know
> >it will be interested/join, and those who are unable to learn it can
> >still work on aMSN1. Added avantage is easy porting to another toolkit.
> >If someone decides he wants a GTK+ aMSN2, he can fork the Python core
> >and write his own UI.
>
>
> I agree wholeheartedly with all the points raised by Philippe. I would just
> like to add that I've got experience with the wxWidgets python bindings, and
> they're great. I can say the same about the dbus and gstreamer bindings as
> well. And please believe me, you do not want to write dbus nor wxWidgets (or
> any other UI toolkit) bindings from scratch just to get started. It's rather
> obvious why wrapping a whole UI toolkit is a lot of work, but probably not
> as obvious for the dbus bindings. Telepathy makes extensive use of recursive
> types and really push the existing bindings to their limits, and getting all
> of this right while at the same time writing everything from scratch is more
> work than I'm sure anyone on this project is willing and able to devote to
> it (after all it's not where the fun is).
>

who needs bindings to wxWidgets ? who needs bindings to Telepathy or gstreamer or whatever.. all we need is bindings for DBUS.

Well, just as an example it's very handy to have GStreamer bindings in case you want to construct a custom pipeline. Say you want an incoming webcam stream to be used as an outgoing stream as well, while at the same time logging it to disk. Or in another pipeline you might want to insert an effects element so that you get PhotoBooth-style effects on one of your outgoing video streams, and for example audio effects applied to one of your voice conversations. With GStreamer the possibilities are endless.

> That said, I really hope this doesn't turn into another language X vs
> language Y thread. :-) There's pros and cons to every possible choice, but
> all things considered, I think python is a great choice for the following
> practical reasons (I won't go into subtle language details):

that already happened and you can read the thread if you want... but as you said, pros and cons for everything, but I think in our situation
Tcl has a far greater pros/cons ratio than any other language (I'm talking about the 'logic core, data storage' ONLY).

Hypothetically if you're right, is it worth the months/years it takes to write all the prerequisities and all the time needed to maintain them?

> - existing, mature bindings for dbus, wxWidgets, gstreamer, Linux desktop
> APIs, Win32 APIs (to give you an idea of how extensive this support is I've
> written a cross-platform wxPython multimedia app that embeds a Windows Media
> Player control in the UI on win32 (using COM), with lots of custom drawing
> in the overall UI, 100% skinned. no native code involved at all.)

We don't need that.. any GUI code will be in the C GUI module anyways... the Tcl part will only be if/else/switch/for/while.. a LOGICAL
unit... + a way to store DATA...
The project will consist of multiple layers, most of them in C and the logic + data layer will be in Tcl...

And all of this is implementable in one evening up to the point where the resulting client goes online, shows your contacts and has basic messaging capabilities? Because that's how long it would take to do the same _today_ in the way suggested. (There's already a working MSN connection manager written in python that can be used until msnlib is done, and the switch will of course be painless because of Telepathy).

> - a majority of aMSN's contributors were new to coding and learnt the
> language on the fly, and this pro still stands with python. it would however
> be lost if moving to a lower level language.

it's not the same, Tcl is a language that can be learned so fast, you can't compare it to other languages.. + many of us were FORCED to
learn Tcl to work with aMSN, but now that we have a choice.. we don't want those other solutions.. and in my case especially python!!!

Python can be learnt just as fast.

> - lots of experienced developers are familiar with python, and I think
> there's a reason why "nobody" writes tcl-bindings for stuff nowadays :-)

who needs them :P lol.. I mean we have a lot of experienced devels in the team, but noone is working, so I don't see why we should add more
'inactive' developers :P
Seriously though, Tcl is too easy to learn, not comparable to python (although, I don't fully know python, but I just hate that indentation
syntax:@) + python users can learn Tcl, but our already used to Tcl guys don't want to learn yet another new language. Especially if it's
not appealing.

You're obviously judging a language that you've never really given a try. The indentation syntax tends to be met with prejudice, even I misliked that until I had used it for 20 minutes. Aside from the lowered potential for errors (having one way to have a block of statements instead of two, like in C), it also provides the benefit of consistency -- you literally force the developers to indent their code and stick to one style, resulting in clean, readable and maintainable code all across the project.

> - existing code for Telepathy clients that can be re-used, including custom
> widgets like for displaying animated emoticons
> - widely accepted even on today's Linux desktop, meaning less dependencies
> for the user
>

Tcl too..but anyways, compilation will be needed no matter what... + btw, isn't it like perl ? not all is installed by default and the user
has to 'cpan' install new modules for adding the needed bindings ?

I don't think it's any different from TCL in that perspective. The win32 python distribution contains tk (ewww) and an IDE, for example. Most Linux distributions ship bindings for dbus, UI toolkits, etc.

> Regards,
> Ole Andr?
>
>
> Regards,
> >Philippe
> >
> >-------------------------------------------------------------------------
> >Using Tomcat but need to do more? Need to support web services, security?
> >Get stuff done quickly with pre-integrated technology to make your job
> >easier
> >Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> >http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> >_______________________________________________
> >Amsn-devel mailing list
> >Amsn-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/amsn-devel
> >

> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Amsn-devel mailing list
> Amsn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amsn-devel


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Amsn-devel mailing list
Amsn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amsn-devel

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Amsn-devel mailing list
Amsn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amsn-devel

Reply via email to