> > What happens if their web connection goes down? Or if they are in Europe,
> > and pay per minute for net access? What if they want to work with the data
> > on a train? Incorporate it into a report for their boss? How about a
> > presentation? Maybe they want to put it in a spreadsheet to rearrange it
> > in some way...
> >
> If their web connection goes down, I suppose they must just try again when
> it comes back up, just as if there is an ice storm, one refrains from going
> to the library (unless one is suicial) until the weather improves. If that
> happens too often, they ought to switch to a moe reliable ISP. If they pay
> per miute for access, that is too bad, but I'd bet that it would still be
> much less expensive to access my site than it would be to actually buy the
> same amount of information in technical reference books. And if they are on
> a train, it is rather difficult to get into the nearest library (unless you
> know of trains that are better equiped than any I have seen.
>
> There are always limits to everything we do, and I can't control everything.
> But I'll not use that as an excuse to make it easy to violate copyright.
Although it's hard to argue without knowing exactly
> It
> would be catastrophic for both the conent providers and me if it was
> trivially easy for our protected materials to be copied and placed on a
> pirate website: that would deny us our right to control the terms under
> which our materials are used and infringe on our rights to be paid for the
> work we do.
How do you think other websites cope with this problem?
> I'd let the content providers decide what they think is fair
> use of their materials,
In the US, the UK, and doubtless many other jurisdictions, this is
completely wrong. The _law_ defines what is fair use, not the content
provider.
> > Is it not a legal grey area? If you take their data, process it and
> > re-present it, I think the user has a strong case that they retain the
> > copyright on the "new" version of their data. But this is a digression.
> >
> But if the content provider wants to make his content easily available, that
> is his right. The user of that content has no such right unless assigned by
> the content provider. A suitable metaphore would be that of books. The
> person who would be paying for access to any onformation on my site would be
> in the position of a book lover, while the content provider would be in the
> position of the author.
In books, you have the "first sale" doctrine. After I pay for a book, I
can do what I like with it - keep it, give it away, burn it. Surely after
a user has paid for your content, they should (again, in analogy with
books) be allowed to do what they like with one copy of it, as long as
they don't break copyright law by reproducing it.
> > Mozilla can be embedded as an ActiveX control; however if you do this, you
> > are restricting yourself to the Windows platform.
> >
> If I can do this, then I should also be able to embed it in a plain DLL or
> even in a monolithic exe. Right? But even with using an ActiveX control,
> I'd be no worse off that I would be with the activex control for IE.
Note that going down this route means a) you have to write something to
embed it into, and b) you can't ever have a Linux version. You'd be better
off just doing a custom version of Mozilla. But anyway, you are probably
better off in netscape.public.mozilla.embedding , at least initially.
> If I find I have come up with something that would be useful to the mozilla
> project, I would not hesitate to contribute. I am, afer all, benefitting
> from being able to access it. And as long as I can control the user
> interface using my own code, I would probably not be modifying the files
> from mozilla. But I will not know for certain until I see the code.
Well download it and play around, then :-)
> > Surely you want a Java applet?
> >
> No, a) because I am not too impressed by Java, and b) because it's securty
> model is not supposed to have access to the client hardware and the programs
> I am considering need to be able to read data from the client's drive, write
> results to the client's drive and optionally be able to print. Now, it may
> well be that he security model for Java applets has been made more flexible
> since last I used it, but it is farily easy to write DLLs in C++ and load
> and unload them dynamically.
I believe applets can be signed, and if you have control of the browser
you could distribute the required certificates with it. This would disable
the security model for applets you approve.
It is indeed easy to write DLLs in C, but getting Mozilla to download them
and load them itself will take work. And be a security hole unless you are
careful.
> > In what way? Does the current DOM not serve your needs?
> >
> That remains to be seen. In a sense, what I am asking is analogous to a C++
> programmer considering whether or not he can create his own library of
> functions and classes. I know that by extending the IDocHostUIHandler
> interface for the IE activex control, I can extend the DOM. I won't know in
> what ways I will want to extend it until I examine it in more detail, but it
> would be good to know if I can do the same with mozilla (and like IE, do so
> without messing with the browser's own code).
As I understand it, the DOM is a generalised API for access to a tree - in
Mozilla's case, an XML one. In which case, the only need to extend it
would be to perform operations on the tree that the current standard
didn't permit or hadn't thought of. I think most ops one could possibly
use are now in - can you give an example of how you might want to extend
it?
Gerv
