[gnome-network]Re: gnome-network for inclusion in 2.6
- From: Rodrigo Moya <rodrigo gnome-db org>
- To: Mark McLoughlin <mark skynet ie>
- Cc: desktop-devel-list gnome org, gnome-network-list gnome org
- Subject: [gnome-network]Re: gnome-network for inclusion in 2.6
- Date: Fri, 24 Oct 2003 12:46:43 +0200
On Fri, 2003-10-24 at 12:23, Mark McLoughlin wrote:
> Hi Rodrigo,
> One of my worries about gnome-network is that I feel its a pretty
> eclectic mix of things to have in a single tarball. I'm not convinced
> they really all belong together .. e.g. if you make an application use
> libgnetwork, do you really want people to have to install the remote
> desktop stuff in order to build the application
libgnetwork has been separated to a different module, and will be
released independently in the next release.
> or if you want the
> transfer manager, why do you have remote shell client. I suppose what
> I'm saying is that different bits of gnome-network seem to be targetted
> at completely different user bases.
well, I've thought about making gnome-network a meta-module, and was so
for the tsclient part. Although as I had many problems with that setup
while doing make distcheck, I removed the only independent module. If
there is really interest in having the tools separated, then we can put
back that sort of setup, having gnome-network containing the basic
tools, and the others being separated modules.
> How about splitting it to different modules e.g.:
> + libgnetwork: networking related libraries (I actually think it might
> make sense to split up the library too - but keep the individual
> libraries in one module)
this is done, and the basic libgnetwork is what was called before
libgtcpsocket. That will be the basic one, and I was thinking on having
a libgnetwork-gnome library, for gnome-only stuff, like gnome-vfs, some
> + gnome-remote-desktop: remote desktop sever and client.
yes, this makes a lot of sense.
> + gnome-file-sharing: the web server and the SMB, NFS etc. support you
> do later.
> + gnome-network-tools: remote shell client and network info tool.
this is fine, as long as we can manage all of them easily in one module,
since having to maintain so many separated modules might be a bit
] [Thread Prev