SteveKing <steveking@gmx.ch> wrote on 02/22/2005 04:09:57 PM:
> Mark Phippard wrote:
>
> > I guess I did not realize that you only planned on receiving a
specific
> > XML file. Since you were talking about this in the context of RegEx,
I
> > thought you were planning on receiving the same HTML file a browser
> > receives and use RegEx to extract the issues. That is why I kept
> > referring to it as HTTP-scraping. I agree that if we are going to
define
> > a new XML format and expect bug trackers to support it, then it is no
> > different.
>
> Parsing a html file to find the issues is something that's not possible
> in a way it would work with all issue trackers out there. And it would
> be much more work and be error prone.
> The well defined XML file is much better here.
I do not disagree. I thought you were going to have properties for the
RegEx that would do it. Since it is a property, you would just have to
supply a working RegEx. I do not really understand RegEx enough to know
if it is even possible. Also, I am not suggesting you do this, it is what
I thought YOU were suggesting.
> > I still think the solution I proposed is better. In my solution, TSVN
is
> > just putting a framework in place that the bug tracker has to fill on
the
> > client. TSVN could provide a default implementation that would work
with
> > unauthenticated XML, but anything else leaves it to the bug tracker.
>
> That might work. If we provide at least the use of an XML file which can
> be fetched unauthenticated then it would work for most people, and all
> others still could implement their own solutions.
>
> > While it is probably more difficult to build an integration on the
client
> > side, I think it is better since one person can write a smallish
client
> > program that anyone using Bugzilla or Tigris can use. Where as a
> > server-side solution requires Bugzilla, Tigris etc. to write it, and
make
> > it available on your project. For example, how long before
SourceForge or
> > the other bug hosting sites provide this to projects they host, even
> > assuming that their underlying issue trackers are enhanced for it. But
> > one motivate programmer can solve it for all SourceForge projects on
the
> > client.
>
> Since providing an XML file isn't difficult and can be done in a day
> with e.g. PHP, I don't think that issue trackers won't implement it if
> users ask for this feature.
> Also, parsing the html would stop working every time the issue tracker
> changes something in the UI.
I think you are nuts on this one. When is the last time tigris.org
updated anything? SourceForge usually isn't very quick to update either.
I think if you did not have some kind if direct control over the server,
odds are you would NEVER see this feature added.
> > Also, having a client-side program pushes the issue of things like
> > authentication on to someone else, and also opens the door for
supporting
> > non-HTTP solutions.
>
> That's a good argument. I'll think of a way to implement calling such
> client-side scripts.
In my opinion, the key is that the client you call ought to provide all of
the UI and TSVN should just wait for the process to end and read what the
user selected from a temp file that the client writes to. A browser app
could even do this using an Applet or ActiveX if the user is dumb enough
to let it. The other way to do this would be for the client you call have
to produce the complete XML file and you then read it and present the UI.
Actually, I guess technically either way could work fine. I was just
thinking that since authentication will still be an issue, it would be
better if the "Select UI" were its own user-initiated dialog. That way
any login prompts the client has to supply are more predictable.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Tue Feb 22 22:23:37 2005