On Fri, 11 Aug 2006 09:45:31 +1000 David Seikel <[EMAIL PROTECTED]> babbled:
> On Fri, 11 Aug 2006 08:01:33 +0900 Carsten Haitzler (The Rasterman) > <[EMAIL PROTECTED]> wrote: > > > On Fri, 11 Aug 2006 08:07:56 +1000 David Seikel <[EMAIL PROTECTED]> > > babbled: > > > > > On Thu, 10 Aug 2006 23:13:50 +0900 Carsten Haitzler (The Rasterman) > > > <[EMAIL PROTECTED]> wrote: > > > > > > > i can be tipped to ecore given some arguments :) but as i said - > > > > > > Arguments to tip you to ecore_desktop_* for the parsing code - > > > > ok- make it an ecore_fdo blob (ecore_fdo sounds good? or > > ecore_xdg?) :) > > I thought about that. This is not the only fdo spec that we now, > or might in the future, support. The other specs may or may not want > to be covered by ecore_fdo, as their specs cover all sorts of different > things. Xdg also covers all the other fdo specs. I think ecore_desktop > is best, as this code deals with all the .desktop related stuff. hmm - so you plan on covering the fdo menu spec elsewhere? > > > > it should also be flexible to be able to parse added fields that > > > > we may add ourselves (the fm2 .desktop parser handles a small set > > > > of fields - and one of them is custom to fm2 - the Type member > > > > (also i recycled the URL, Name, Comment etc. fields). > > > > > > All fields that are in the .desktop file are included in an > > > Ecore_Hash, some of them are also decoded into specific fields of > > > my Fdo_Destop structure. I have no issue with adding more fields > > > to that structure as time goes by. > > > > cool. what i see would be best is that the load is cone with the > > ecore hash but then this is copied into a "static" struct on the e > > side (since we will be loading 100's or 1000's of .desktop entries - > > if each has their own hash this is rather expensive memory-wise). > > > > the other option is - we make the only source of a load the "cache" > > and nothing gets loaded until it goes into the "cache". so there is > > code that loads and then adds to the cache - telling the "real" load > > to "ok - look in cache now!". now cache becomes a mmap()'ed file, > > already laid out in an architecture-independent way (no pointers, > > just offsets for indexes) and thus this data is just mmaped() and > > thus will be paged by the kernel as needed and only what is needed is > > in memory - and if more than 1 process needs this data - it will > > share the cached map. > > > > ??? > > I'll get it in first, THEN worry about caching options. B-) well it could be a full design decision from the get-go :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
