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.
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..
That would be simpler than rewriting almost the whole protocol abstraction
layer to make it compatible with a telepathy backend, wouldn't it ?
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
