On Sun, Aug 29, 2010 at 6:01 AM, Arantes <arantes...@gmail.com> wrote:
> Hello guys,
> Just wanted to say ... I really don't like this. Not because of the use of
> DBUS, or the multiprocess or not, but because i really think that if we do
> that, aMSN won't be aMSN no more. It would just be another multi protocol
> client, like there are tons of. I really think aMSN should stay a msn-only
> client, that's how it can be the best at it.
>
Yes, we know that, we already do, and that's why we always wanted aMSN to
stay MSN specific, and I don't think we plan on stopping that! the
multiprotocol is a 'bonus', but we'll stay MSN-centric, we'll continue to
support the MSN protocol as much as possible, the UI will stil keep the WLM
look&feel, etc... we'll just change the protocol backend/technology, which
itself allows us to go multi proto...
Besides that, i can't really have an opinion about that dbus and telepathy
> stuff, cause i don't know enough about that, but i can't understand why
> making amsn2 able to switch FE would need a client daemon structure. Why
> couldn't we just keep the same structure as now and add to the core the
> ability to "kill" a front end, then launch another one ? Of course we would
> need to implement a lot of stuff, like that the core should not only pass
> all the messages to the FE but also keep them to be able to re send them to
> the potential new FE..
>
Because you can't.. if you launch the process somewhere for the GTK/QT
frontends, then connect through ssh then you can't just ask it to start
sending the curses front end on your terminal...
> That would be simpler than rewriting almost the whole protocol abstraction
> layer to make it compatible with a telepathy backend, wouldn't it ?
>
nah, the 'whole protocol abstraction' is quite small and simple, we're not
rewriting the whole protocol, just the protocol layer. Look at
amsn2/protocol/client.py (
http://github.com/amsn/amsn2/blob/master/amsn2/protocol/client.py ).. that's
pretty much all we need to rewrite... there are some files in events/
subdir, but look at them.. not much.. so when you say "rewriting almost the
whole protocol abstraction layer" I don't think it's too much of an issue
compared to the gain.
An advantage of telepathy, is for example when you said "we need the core to
save the messages in order to pass them back to the new FE".. there's no
need for that.. we could use the telepathy-logger! amsn2 itself doesn't need
to be saving logs, because telepathy has its own 'logger' process which acts
as an 'observer' on the channels.. so if you wish to switch front-ends, you
can just ask it to re-print it the last X lines of conversation or
something.
(and btw, it gives us the advantage that the logs will be in the same format
and compatible with empathy, etc.. )
>
>
> Le 27 août 2010 à 02:23, Alaoui <kakar...@kakaroto.homelinux.net> a
> écrit :
>
>
>
> On Thu, Aug 26, 2010 at 8:45 AM, Boris 'billiob' Faure
> <bill...@gmail.com>wrote:
>
>> 2010/8/26 Stéphane Bisinger <stephane.bisin...@gmail.com>:
>> > I think that if we want to split daemon/client, telepathy is an
>> > eccelent option since we would basically do the same thing with an
>> > implementation of our own. So the question is: would it be a good idea
>> > to split aMSN2 in a client/daemon structure?
>>
>> that's the goal. The way we use views is a bit like client-dæmon anyway.
>>
> Well, aMSN2 has always been a telepathy-like framework, with small
> difference... first, it's uni-process, secondly, you don't give UIs any
> information they don't need, you just tell them "what to draw" where as
> telepahy tells the UI all the information and the UI decides what to do with
> it (which is important for their use case).
> So the real question is "since we're doing pretty much what telepathy
> does.. should we drop our uniprocess requirement?"
>
>
>>
>> > Based on what I see from the centerim project, a LOT of people use a
>> > similar functionality, where you can start centerim in the background
>> > and do things from the command line. This is very much like having a
>> > daemon and a client which is only command line.
>> > With the described structure we would be able to do more and do it
>> better!
>>
>> And if the client can not contact the daemon, it should be able to start
>> it.
>>
> With dbus it just works, you request a service, and the dbus daemon will
> spawn the process for you.. same when the process dies, the dbus daemon will
> respawn it automatically for you if you still want it.
>
> @Stephane: About the dbus requirement, well that's not really the issue..
> yes, now pretty much every computer has it.. oh look, even my headless
> server! And even if you don't have it.. once you apt-get install amsn, it
> would just be brought along with it... Also, GNOME now has empathy as its
> default IM client. So that means that every GNOME user already has
> telepathy.
> Anyways, the size doesn't matter, the dependencies don't matter.. the only
> reason (for me anyways) to say "not like the dbus dependency" is because I
> don't like dbus itself, not because of the dependency... There was also an
> issue of "would it work on windows" but afaik, it's windows-compatible (TM).
> Finally, I'd like to point out that even though dbus is a bitch to work
> with, we'll be using python.. and python-dbus is JUST AWESOME! Very easy to
> use actually.. and as luck would have it, a few months ago, I wrote a big
> python framework to make the use of telepathy/dbus as easy as possible.
> Have a look here :
> http://gitorious.org/teamgeist/teamgeist/blobs/master/tp_classes.py
> Basically.. you want a Channel, then do :
> class Channel (BaseChannel):
> you want to listen to the 'HandleChannel' dbus signal, then do :
> method HandleChannel ( ... )
> that's it.. the base classes will look for the method names, and
> automatically do introspection on the objects and connect the signals, or
> send the dbus methods when you call a local method, etc...
>
> so, actually dbus + python.. I don't mind that dependency that much...
>
>
>> --
>> Boris 'billiob' Faure
>>
>>
>> ------------------------------------------------------------------------------
>> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
>> Be part of this innovative community and reach millions of netbook users
>> worldwide. Take advantage of special opportunities to increase revenue and
>> speed time-to-market. Join now, and jumpstart your future.
>> http://p.sf.net/sfu/intel-atom-d2d
>> _______________________________________________
>> Amsn-devel mailing list
>> Amsn-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/amsn-devel
>>
>
>
> ------------------------------------------------------------------------------
> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
> Be part of this innovative community and reach millions of netbook users
> worldwide. Take advantage of special opportunities to increase revenue and
> speed time-to-market. Join now, and jumpstart your future.
> http://p.sf.net/sfu/intel-atom-d2d
>
> _______________________________________________
> Amsn-devel mailing list
> Amsn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amsn-devel
>
>
>
> ------------------------------------------------------------------------------
> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
> Be part of this innovative community and reach millions of netbook users
> worldwide. Take advantage of special opportunities to increase revenue and
> speed time-to-market. Join now, and jumpstart your future.
> http://p.sf.net/sfu/intel-atom-d2d
> _______________________________________________
> Amsn-devel mailing list
> Amsn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amsn-devel
>
>
------------------------------------------------------------------------------
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users
worldwide. Take advantage of special opportunities to increase revenue and
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
_______________________________________________
Amsn-devel mailing list
Amsn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amsn-devel
