Re: [iSVG] Change list for iSVG

[Robin B. <ro...@kn...>]

On Sunday 16 September 2001 22:40, Antoine Quint wrote:
> Ok, we'll have the namespace hosted somewhere else... I'm just not sure
> where? On graougraou.com I guess...

Well as long as it's under control it's not much of a problem. Theoretically, 
severage.sf.net is best hosted elsewhere, so I guess that "elsewhere" is the 
best place.

> Well, it is just an acronym for what it is... I don't think we need
> something fancy, iSVG is just a subproject anyway... Like XSP or XPS if
> you will.

Ok, nevermind. The internal project here is called kestrel because it sounds 
like a cute little name for a windowing system, but who cares. It's just that 
people remember names better than acronyms.

> Hmm, I guess this is going to be pretty hard. I've been following
> persistent guidelines on the most recent iSVG developments. But I'm not
> sure you'll like all of them.

It's not so much about me as it is about the world at large. People will not 
use settings that are not standard. What I listed above is part of what 
everyone uses when communicating at large in projects.

> That's what I thought, I think I'll just email the svg-list about
> this... that is only if I can sort out the awful stuff that's been going
> on with my yahoo group account.

I can post there myself. One thing that I'd be interested in knowing is if 
there's a way to add missing methods to Adobe's interface. I think there's 
something about that in E262, chapter the Object object.

> There are comments already, but I don' think they would stand for
> documentation purposes. I think the doc has to be seperated since the
> script files have to be kept at the smallest weight.

No, it really is best to include the doc inline. What Java does here (I'm 
thinking about that because it has a similar syntax) is that all comments 
that start with /** are documentation. We could use something like that, 
together with simplistic XML tags in those comments to give a touch of 
structure. If we don't do that it'll never be commented.

Weight is not a problem, there'll be a pre-processor that'll generate a 
version with no embedded doc. We'll need a build preprocessor anyway if we 
want to stay sane. I think the best _usage_ format is to have the entire 
library in a single gzipped file, but the best dev format is probably to have 
a lot of smaller special purpose files. The build preprocessor would 1) put 
all the files into a single one, 2) extract all the doc, remove it from the 
source, and save it to a doc file, 3) gzip the es file for release. That'll 
make our lives a hell of a lot more easier, all that with a stupid 20 lines 
preprocessor.

--
_______________________________________________________________________
Robin Berjon <ro...@kn...> -- CTO
k n o w s c a p e : // venture knowledge agency www.knowscape.com
-----------------------------------------------------------------------
An eye for an eye will make the whole world blind. -- Mahatma Gandhi