Le 17 juil. 07 à 01:32, David Chisnall a écrit : > On 17 Jul 2007, at 00:21, Yen-Ju Chen wrote: > >> I think it is a good idea about puting it into EtoileFoundation, >> but probably after 0.2 release. > > I'll start renaming the classes to from TR* to ET* in preparation, > and add it after 0.2 is out if no one has any objections.
I haven't :-) >> Then we can think about how to organize the EtoileFoundation. >> For example, there are classes handling thread in EtoileFoundation >> while there are also EtoileThread. >> My idea is to have them as subprojects of EtoileFoundation > > So EtoileFoundation becomes a meta-framework, and people can just > link to the individual frameworks if they don't need everything? > Seems sensible. I'd like to put EtoileThread into EtoileFoundation. Subproject doesn't mean necessarily subframework or sublibrary it could be purely organizational, but I think subframework is clearly better in that case. We should probably have within EtoileFoundation: - Headers <-- headers part of metaframework by default - Source <-- source code file part of metaframework by default - EtoileXML/Headers - EtoileXML/Source - EtoileThread/Headers - EtoileThread/Source At each level you can add additional directory along Headers and Source if you need to package more stuff resources, images, tool/ dameon or plugins. >> Another thing is that the use of TRXML for Vienna is >> because NSXML is not complete and TRXMLParser can tolerate >> for bad syntax or truncated xml. >> So I think we need to define what TRXML does so that it won't >> expand >> to be a full-featured XML parser identical to NSXMLParser. > > I have no intention of writing a full-featured XML parser; there are > enough of them already. TRXML was meant to support the 10% of XML > that 90% of people need. If you need a full XML parser, there's > libxml2, and there will be NSXML* eventually. If you just need to > deal with simple XML data then there's EtoileXML[1] :-) Fine. >> There are a few classes in Vienna dealing with XML which may be >> useful, >> for example, parse date string using libcurl (expensive and should >> be rewritten), >> pre-process XML data to eliminate bad syntax before parsing, >> estimate encoding before xml parser which use string instead >> bytes (NSData). >> >> By the way, Vienna is under Apache 2.0, >> which should be compatible with EtoileFoundation. > > I'd have to check, but as I recall Apache 2.0 has a patent defence > clause that makes it incompatible with GPLv2 (GPLv3 has some extra > Apache 2-compatibility conditionals). I don't have a problem with > making EtoileFoundation incompatible with GPLv2 (although I'd like to > keep it compatible with v3 if we can), but I think we should see if > anyone else has any objections. I think we have GPL2 applications like Grr, Vindaloo that use EtoileFoundation. I would prefer to keep it GPL2 compatible easpecially for the following reason, EtoileFoundation is linked by EtoileUI which in turn will be linked by a new framework EtoileKit implementing high level Étoilé specific concepts and UI behaviors. So all Étoilé applications are going to link at least these three frameworks on release 0.3. The problem is to find the right balance between dependency chain, reusability/sharing and features worth to provide by default. At some point, I will post another mails about upcoming framework organization, EtoileKit, Container etc. > David > > [1] EtoileXML? ETXML? Is the convention to use Etoile* for the > framework name and ET* for the prefix? Yes. The framework naming rules are (I mean the ones I use until now in an instinctive way :-): - low level key system framework uses Core like CoreObject, SystemCore or SecurityCore - low level system framework which are less central can use System like SystemConfig, SystemShare or SystemLDAP - low level framework packaging classes which aren't UI or system related uses Foundation like EtoileFoundation or AddressFoundation - framework packaging mostly views or UI elements related classes uses UI like EtoileUI, AddressUI or SecurityUI - big Foundation-style framework without UI counterpart, framework mixing UI/Foundation stuff or framework that doesn't fit in another category uses Kit like EtoileKit, OgreKit, MultimediaKit, CollectionKit or LuceneKit - small framework that handles only little things and cannot be broken in Foundation/UI style framework uses Etoile prefix or no prefix/suffix, like EtoileThread, DistributedView (only one view class) Let me know about your criticisms and suggestions. I plan to update HACKING document with these rules. Some frameworks don't conform to these rules yet. We may fix some of them when it makes sense as we go along. For prefix, the default prefix is ET for classes but its use should be reserved to EtoileFoundation, EtoileUI and EtoileKit. It should be used in any subframeworks of the previous ones or any frameworks with Etoile prefix/suffix in its name. For all other frameworks, using a distinct prefix should be the rule. > Do we even have a guideline > for this yet, or are we still making it up as we go along? Now we have an official one under evaluation ;-) Cheers, Quentin. _______________________________________________ Etoile-dev mailing list [email protected] https://mail.gna.org/listinfo/etoile-dev
