Hi, James and all

The name transmission-daemon can be confusing. It's not the traditional
daemon that might be in your mind. 

Transmission provides different way for different users according to
their habits of using software. As I talked with Elaine, and from a
user's point of view (not a developer's), it turns out that there're
several ways of using "transmission" 

1. For users who like to to user GUI, they can
use /usr/bin/transmission, which is a GTK based GUI. 

2. For users who likes to use command line in a terminal, they can
use /usr/bin/transmission-cli, which provides more flexibility for users
to script according to their preferences. 

3. use /usr/bin/transmission-daemon and /usr/bin/transmission-remote .
[1]

4. use Clutch and /usr/bin/transmission-daemon. This is a little tricky.
First Clutch is not part of the package that this project will ship,
it's a WEB GUI. The server for the WEB GUI is a remote server (who ever
like to run it), which has nothing to do with the "transmission" project
that we are ARC'ing.
Users run an instance of /usr/bin/transmission-daemon on their local
box, then access Clutch -- the web GUI, then Clutch will be able to
communicate with transmission-daemon and do the work. 

Elaine, please correct me if my understanding is incorrect. 

The manpages for all the binaries are available at 

Internally
http://sac.eng/Archives/CaseLog/arc/LSARC/2008/450/manpages/

Externally 
http://www.opensolaris.org/os/community/arc/caselog/2008/450

--Irene 

[1] It seems to me that features(transmission-remote +
transmission-daemon) is a subset of features(transmission). Therefore,
even if transmission-remote and transmission-daemon are not shipped, the
users can still use transmission GUI to do all the work that this
project may provide.

On Thu, 2008-07-17 at 15:14 +0800, Elaine Xiong wrote:
> James Carlson ??????: 
> > Elaine Xiong writes:
> >   
> > > James Carlson ??:
> > >     
> > > > Not "can" but "would."  What's the usage case that involves an
> > > > ordinary user invoking these things?
> > > > 
> > > >   
> > > >       
> > > These programs facilitate the ordinary user to manage all the torrents 
> > > in more flexible mode. The strong usage case is 
> > > Transmission-daemon+Clutch that allows the user easily controls 
> > > Transmission-daemon through a Web GUI without running Transmission(gtk 
> > > GUI).
> > >     
> > 
> > That doesn't sound to me like a user executing transmission-daemon
> > from the command line, which is the design intent of /usr/bin.  It
> > sounds more like a web server that invokes this tool as a utility
> > program; likely out of /usr/lib or even some cgi-bin directory.
> > That's rather different, even if the user experience is that he
> > invokes it "directly" through a web GUI.
> > 
> >   
> Transmission-daemon is in no way a web server. It's just a back-end
> detaching from Transmission. One benefit is to allow the user choose
> the favorite front-end. Actually in the case of daemon + Clutch ,
> Clutch WebUI should be put into a web server to run that. Please note
> that Clutch doesn't pertain to Transmission package. Furthermore
> Transmission-daemon is not a system daemon/service. It's just a
> session daemon started by the ordinary user in command-line. Although
> it has a name of daemon but I think it only means running in the
> background.
> 
> > > Another usage case is the example in the manpage,
> > >     
> > 
> > What man page?  None seems to be in the case directory.
> > 
> >   
> I'll update the manpages into the case.
> > > It can list all the torrent tasks on jade using proxy command. In brief 
> > > the ordinary user would like to choose the favorite front-end to connect 
> > > with Transmission-daemon which means less resources.
> > >     
> > 
> > It's unclear that I'm getting my questions across, and the case seems
> > to lack archived reference documentation, so I'll call it a day.  If
> > you (and the LSARC members) feel that this is the right way to
> > integrate this feature, then drive on.
> > 
> >   
> Thanks for your concerns, 
> -- 
> Best Regards,
> 
> Elaine Xiong
> Sun Microsystems
> Email: elaine.xiong at sun.com
> Tel: (86-10)62673501 ext:80501
> Mobile: (86)13681214262


Reply via email to