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
