Well clearly from our point of view then this is all something we have
had for years. And from our point of view then taking some sort of 180
degree turn just because others are finally waking up does not make any
sense.
I also do believe that what ever way will be used then it wont mater a
whole lot, reading the version info is very insignificant thing and
users are not likely to in some sort of Browser war over it. If using
browser from us or someone else is not likely to mater a lot to the
normal user even if possibly missing a few tags.
If some tags come that makes sense then we might support it if we see
significant benefit from it for users.
As for if we will kill our product then no definitely not (unless if
there was no user base left). To rely on open source solutions or some
sort of community work has not worked well for us in the past, it
benefits our self's and our users that we can move fast and take quick
U-Turns without having to be depended on someone else to work quickly
when its needed. The change to using only our own tools (Everything
from Post Linkers, Issue Tracking systems to Documentation generators
which happened more than a year ago has greatly improved the quality of
our products which again makes happier users). With this in mind then
even if this tool is insignificant (now at this moment) then going with
community solution does not fit in our rapid model at all, it would
kill our future plans and higher purpose for this tool. Infrastructure
is one of our strong side, and we plan to keep it like that.
I gave the spec free which enables anyone to make compatible and even
extended browsers (and also the tool is for free for those who don't
want to make their own). If everyone use the same reader should not
mater at all, and such can even make it worse in the long run since a
single solution makes you miss out on all the good ideas (where would
we be if Internet Explorer was the only web browser ? - after All MS
had no teams working on it any more because they thought they had won
the browser market, so no improvements were supposed to come).
The format is highly extendable, its easy to support the basics and
easy for others to be compatible with that. Its even easy to support
tags that the browser does not know of.
As for eliminating the first optional line then the "optional" word
indicates that it is optional, so little need to eliminate it.
On 24.5.2005, at 03:19, Brendan Murphy wrote:
So Bjorn is not going to open source his plugin tool or the tools
necessary to build the version file, then we must look elsewhere
for that part of the solution. This is no big deal, but when we
come up with an open source solution then what purpose does
Bjorn's plugin tool serve? The answer is I think it will become a
distraction since we want our end users to use a single tool. The
question is will you (Bjorn) pull your tool from the market or
remove the cross over functionality? My guess is you will probably
not, so we will end up with a fragmented choice for the end user.
More important than the plugin tool itself is the format of the
version file. Undoubtily there will be additions to the fields
based on the discussions going on in this news group. Again, will
you (Bjorn) support and follow what is decided upon here?
I hate to be single you out here (Bjorn), but you have put us in a
slight quandry. If nobody had done anything along these lines and
we were starting from a blank slate, this would be so easy. To
make this process work seemlessly for end users, we need your
coorporation. I think there needs to some kind of comprimise on
your part for the good of the community (most likely supporting
new fields as we go forward).
-----
After we establish the necessary infrastructure to support the RBX
format, we (as the plugin author community) should stop producing
the old style plugins and go strictly forward with the the RBX
format. In the long run this will better serve our end users and
ourselves having a unified format.
-----
The first order of business is to decide on the what belongs in
the version file. Bjorn's format begins with the following fields.
- Release
- Revision
- Fix
- Status
- InternalStage
- CountryCode
- ShortString
- LongString
I am not sure what is the value of having a ShortString and
LongString other than for lagacy purposes.
What I think is needed are the following fields.
- Vendor (name of the vendor--MBS, Einhugur, TNSC, etc.)
- Comment (free form text)
I also think we should eliminate the first optional line that
Bjorn had for his old reader.
Does anybody else have other proposed additions or comments.
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
|