On Mon, 25 Jan 2010 08:44:54 -0200 Gustavo Sverzut Barbieri
<barbi...@profusion.mobi> said:

> On Mon, Jan 25, 2010 at 12:28 AM, Carsten Haitzler <ras...@rasterman.com>
> wrote:
> > On Sun, 24 Jan 2010 23:40:16 -0200 Gustavo Sverzut Barbieri
> > <barbi...@profusion.mobi> said:
> >
> >> On Sun, Jan 24, 2010 at 8:21 PM, Carsten Haitzler <ras...@rasterman.com>
> >> wrote:
> >> > On Sun, 24 Jan 2010 18:17:28 -0200 Gustavo Sverzut Barbieri
> >> > <barbi...@profusion.mobi> said:
> >> >
> >> >> On 1/23/10, Carsten Haitzler <ras...@rasterman.com> wrote:
> >> >> > On Sun, 24 Jan 2010 00:13:25 +0100 Albin Tonnerre
> >> >> > <albin.tonne...@gmail.com> said:
> >> >> >
> >> >> >> On Sun, 24 Jan 2010 00:02 +0100, Vincent Torri wrote :
> >> >> >> >
> >> >> >> > to summarize:
> >> >> >> >
> >> >> >> >  * ecore_txt moved in eina
> >> >> >>
> >> >> >> I think we'll just have to agree to disagree here :)
> >> >> >>
> >> >> >> >  * ecore_job merged in ecore
> >> >> >>
> >> >> >> I've made a patch doing this.
> >> >> >>
> >> >> >> >  * nothing done for ecore_file (raster wants it in ecore)
> >> >> >>
> >> >> >> Do you mean ecore_input here ?
> >> >> >
> >> >> > no. ecore-file. can't put ecore-file in eina. it stays as ecore-file
> >> >> > or gets renamed to e-file-lib or whatevrr - but thats pointless as
> >> >> > all u are doing is
> >> >> > changing its name. it still cant be used by evas due to ecore-file
> >> >> > needing ecore - and ecore-evas needing evas.  so it stays
> >> >>
> >> >> ecore_file, with the exception of file_download, is very simple
> >> >> abstraction and helpers are generaly useful (rm -r, mkdir -p...) and
> >> >> i'd consider them at the same category as eina_mempool and
> >> >> eina_module, so eina isla good place.
> >> >
> >> > ecore_file ALSO has the file monitoring stuff - which needs a mainloop.
> >> > so... no can do in eina. ecore-file should stay where it is.
> >>
> >> ok, but still against moving ecore_file_dir_get(),
> >> ecore_file_file_get() out of it?! these are basic and some of these
> >> functions are already duplicated internally in Eina for use in places
> >> like ecore_module anyway... ecore_file_rm_recursive and friends are
> >> generally useful, IMHO they should even be in libC/posix, as we can't
> >> change that, so move to eina.
> >
> > then you have some file stuff in eina, some in ecore-file - sounds not so
> > good to me.
> 
> Ok, but you have to agree that file downloading, monitoring and simple
> operations are very, very different. For instance I bet that even
> kernel does not have inotify inside fs/ folder :-P

thhe kernel also does not have a rendering engine, canvas layer, widgets etc.

the structure for userland is different to a kernel, and here i disagree. file
monitoring AND doing things on those files go together. they are in the "deal
with simple files" domain. not interpreting the contents of them, just doing
the "raw bits and pieces".

> I'm rather rename to avoid conflicts:
> 
>     - eina_fs_{cp,mv,...}  (basic file operations)
> 
>     - ecore_inotify or ecore_file_monitor (but it can also monitor
> directories...)
> 
>     - ecore_con_file_download

this is possible the only thing that might move from ecore-file - download, as
it primarily is dealing with a http connection and dumping data to disk as a
simple output. the others imho belong together. (and then you will complain
that ecore-file is too small so it needs to be merged with ecore as all it has
is inotify stuff).

you know with this amount of shuffling - i'd have to put off any alpha release
for maybe 3-6months. accept the consequences of wanting to do such major
shuffling (that is entirely not needed for most of it).


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    ras...@rasterman.com


------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to