>> In the meantime, being able to read and write images in a couple of
>> formats would be nice. I suggest JPEG and GIF
>
>PNG would be better than GIF -- no royalties to pay to Unisys...
I don't think I've ever noticed a site actually using PNG -- I
had to go away and look up what it was when it was first mentioned.
GIFs are free for any non-commercial purpose, so most
poplog users wouldn't be affected.
I wonder if Unisys actually, really, truly charge anyone for
commercial use? I decided to have a look at some commercial
sites. Banks are about as commercial as I could think of, and
the second one I tried, First Direct, had an animated gif on
its home page. I wonder if they pay royalties to Unisys? There
must be literally hundreds of thousands of small, commercial
web sites using animated GIFs. Do they pay?
That's not a reason to use GIF instead of PNG, of course. Except
that, as far as I know, you can't make animated PNG files,
whereas you can do animated GIFs.
If poplog had to choose between GIF and PNG, then I guess it
depends how prevalent the PNG format is in the unix world; I
don't know the answer to that. The de facto standard on the web
still seems to be GIF though, as far as I can tell.
>> I think the solution might be to emulate the kind of "plug-in" API
>> used by browsers and some other kinds of software, both commercial
>> and shareware. Presumably these APIs are less of a moving target, and,
>> if done right, a new version of the plug-ins ought to plug-in without
>> even changing anything in poplog.
>
>Absolutely. That seems to be the way things are done these days -- to
>specify an interface for, say, image-format plugins and then have someone
>else implement them for you.
Both you and someone who e-mailed me privately misunderstood what
I meant. So it must be my fault. I'll try again.
I'm not suggesting that, with a small user-base, we can persuade
lots of people to write plug-ins for poplog. What I was thinking,
was that since the plug-in APIs for things like Netscape, Photoshop
etc. must be known/obtainable, then if poplog provided the same
API for plug-ins, we could piggy-back on the effort provided
for those. For example, if poplog provided the same API as Adobe
Photoshop, then presumably someone who had bought Kai's Power Tools,
which are produced by a quite separate company, could also plug them
into poplog, for image processing. (And ditto for shareware stuff.)
So the last thing poplog should do is specify a new interface; it
should emulate an existing interface.
>> >15. CGI toolkit
>> >
>> > This project would provide a "lib cgi.p" that would let people
(snip)
>> Too late, IMHO. CGI is the past. Servlets and server-side scripting
(snip)
>CGI as a web technology would be waaaay too late now. And I'm not sure why
>anyone would even want to do server-side scripting in pop11. Perhaps this
is
>an argument about the ease of producing stand-alone binaries that can be
>called easily from other applications (like for example webservers).
>Although for efficiency reasons you'd be better off implementing it as a
>separate entity which served requests from the webserver. (Remind me: does
>poplog make much use of multi-threading? Simple multi-threading extensions
>would be a really neat addition if not.)
Yes, I think we agree about this. It occurs to me that a CORBA compliant
library should probably be added for this kind of purpose. And yes, poplog
does allow a kind of multi-threading. As usual, the terminology is
non-standard: in poplog threads are called processes. The only (potential)
problem would be with the scheduling, since separate threads in poplog
use co-operative multi-tasking, i.e. one thread explictly resumes
another (using, strangely enough, a function called -resume- :-). I
vaguely remember years ago (as an experiment) using a timer-interrupt
routine to implement a kind of round-robin pre-emptive scheduling. Something
like that would be a useful library for a server application. Note that
we are talking about threads internal to poplog, not threads as provided
by the OS.
I don't know if the above is out of date: it is several years since I
last used poplog (and I haven't installed Linux yet, which I was planning
to do about a month ago, so can't yet install poplog. But Real Soon Now).
Maybe there is now a library for pre-emptive scheduling of
multiple (poplog) processes? It wouldn't be difficult: all you
need is a list of which processes need to run in parallel, and
a (timer driven) interrupt routine which switches between them.
Of course, to be truly useful you then need to provide various
other things ... (e.g. mutual exclusion around code segments, i.e.
what the keyword "synchronized" is used for in Java.)
Jonathan
|