Bugzilla down - Revzilla loses its mind
david at openpartnership.net
Sun Dec 24 11:07:32 CST 2006
I must in general agree with Richard here. It is really very baffling to me
to see so much effort being put into web front ends and virtually nothing
being put into the basics of showing off the connectivity of the Rev IDE -
that is connecting it to shared online development resources!
Existing open source web front ends for wiki's, blogs and bugzilla are just
fine and do not require any investment at all to install and maintain - they
come bundled with a variety of hosting solutions. What does require a little
investment is building in direct access within the IDE to DEVELOPMENT tools.
Personally I can say that I have filed 3 or four bugs using the browser, and
would have filed 10 times as many reports if it had been built into the IDE,
same goes with the documentation and wiki. I used to file a lot more
directly to Scott Raney - largely because of prompt and personal email
replies. The current investment of resources in web front ends for
developers makes little present sense. This may change when a fully
functional embedded browser is part of the IDE.
On 24/12/06, Richard Gaskin <ambassador at fourthworld.com> wrote:
> In all the many words about why Rev is a bad choice for Internet apps,
> you didn't answer this:
> I don't think anyone's every advocated ditching the
> web UI for the database, but as long as Revzilla is
> appreciated at RunRev why not just bundle it in the
> Plugins folder?
Personally i would advocate ditching the web interface for bug reporting. If
only to get the thinking about what to concentrate scarce resources on a bit
clearer for RunRev. Failure to do a basic install or get web connectivity
working should be a rare occurrence and is serious enough for new users to
warrant reporting by email with a direct response from technical support to
help fix the problem.
That's all I was asking for, that and the reinstatement of a list of
> cool third-party goodies for Rev at their site that is large enough to
> include Revzilla (the current portrayal of third-party offerings gives
> the impression that the installed base is much smaller than it is).
> When Marcus gets back from his vacation, I plan to send him a new GIF for
> > the title bar that pushes the logo/text down a couple pixels. That's a
> > 4-second effort on his part to just replace the image on the server and
> > impact to end users. There was no need to invent the mechanism to do
> > no need to test or debug it; no version control overhead. It just works.
> > Hard to get much easier than that.
> You can use URLs in the fileName property of images and they get
> downloaded on preOpenCard, handy for exactly the same reason.
Ditto. Updating a server side resource is updating a server side resource.
If that is a Gif or a RunRev stack the issue is exactly the same. The
Browser or Rev IDE just downloads these if they are not in the cache. This
works well now. Getting this working as near perfectly as possible is where
the investment should be being placed. When browser based plugins installed
themselves painlessly, or quicktime took the same route many more users came
on board. RunRev should be using the great technology it has, and has been
in lace for a few years now and very much under-used, and building on it.
Web GUI stuff should stick firmly in the province of marketing to new users.
More information about the use-livecode