Special:All pages broken at about 03:00 UTC this morning

[Jay R. Ashworth]

On Wed, Aug 20, 2008 at 10:20:44PM +0200, Roan Kattouw wrote:
> Simetrical is right here: the UI and the API call the same functions,
> and display the results in different ways. That's exactly why there's no
> sense in migrating the front end to the API (and that's just forgetting
> about the HTTP overhead involved).

Um, we mean different things by "API", clearly.  

What I think *you* mean by it is "a thin wrapper over the *actual* API".

Am I wrong?

Cheers,
-- jra
--
Jay R. Ashworth                   Baylink                      jra@...
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com                     '87 e24
St Petersburg FL USA      http://photo.imageinc.us             [phone]

             Those who cast the vote decide nothing.
             Those who count the vote decide everything.
               -- (Josef Stalin)

_______________________________________________
Wikitech-l mailing list
Wikitech-l@...
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Roan Kattouw]

Jay R. Ashworth schreef:

> On Wed, Aug 20, 2008 at 10:20:44PM +0200, Roan Kattouw wrote:
>  
>> Simetrical is right here: the UI and the API call the same functions,
>> and display the results in different ways. That's exactly why there's no
>> sense in migrating the front end to the API (and that's just forgetting
>> about the HTTP overhead involved).
>>    
>
> Um, we mean different things by "API", clearly.  
>
> What I think *you* mean by it is "a thin wrapper over the *actual* API".
>
> Am I wrong?

In MediaWiki speak, the API is api.php . You're probably referring to
the backend functions which *are* used by the UI.

Just to clarify again: the API and the UI call *the same functions*, but
present the results differently. That's why there's *nothing to gain
whatsoever* in letting the UI call the API.

Roan Kattouw (Catrope)

_______________________________________________
Wikitech-l mailing list
Wikitech-l@...
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Jay R. Ashworth]

On Thu, Aug 21, 2008 at 05:10:34PM -0400, Aryeh Gregor wrote:
> * The cost of access.  HTTP requests have very high overhead -- set up
> network connection, pass request through a long chain of servers and
> processes, send result back -- usually on the order of a hundred
> milliseconds or more.  

As soon as I read this, i realize that indeed, you guys are talking
about "an implementation of an interface to the API", not the actual
thing itself.

An API, by definition, is a declared set of call and response
interfaces to a block of core code, with defined parameter domains and
ranges.

It's not the interfaces you use to *get* to that, be it HTML, REST, or
whosoever...

Cheers,
-- jra
--
Jay R. Ashworth                   Baylink                      jra@...
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com                     '87 e24
St Petersburg FL USA      http://photo.imageinc.us             [phone]

             Those who cast the vote decide nothing.
             Those who count the vote decide everything.
               -- (Josef Stalin)

_______________________________________________
Wikitech-l mailing list
Wikitech-l@...
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Jay R. Ashworth]

On Fri, Aug 22, 2008 at 12:01:53AM +0200, Roan Kattouw wrote:

> Jay R. Ashworth schreef:
> > On Wed, Aug 20, 2008 at 10:20:44PM +0200, Roan Kattouw wrote:
> >> Simetrical is right here: the UI and the API call the same functions,
> >> and display the results in different ways. That's exactly why there's no
> >> sense in migrating the front end to the API (and that's just forgetting
> >> about the HTTP overhead involved).
> >
> > Um, we mean different things by "API", clearly.  
> >
> > What I think *you* mean by it is "a thin wrapper over the *actual* API".
> >
> > Am I wrong?
>
> In MediaWiki speak, the API is api.php . You're probably referring to
> the backend functions which *are* used by the UI.
>
> Just to clarify again: the API and the UI call *the same functions*, but
> present the results differently. That's why there's *nothing to gain
> whatsoever* in letting the UI call the API.

If api.php exposes every and only the interfaces already used by the
core code, and the current UI can't cheat and do things api.php does
not expose to the core's state, then yes, my desire and concerns are
satisfied.

Cheers,
-- jra
--
Jay R. Ashworth                   Baylink                      jra@...
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com                     '87 e24
St Petersburg FL USA      http://photo.imageinc.us             [phone]

             Those who cast the vote decide nothing.
             Those who count the vote decide everything.
               -- (Josef Stalin)

_______________________________________________
Wikitech-l mailing list
Wikitech-l@...
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Aryeh Gregor]

On Thu, Aug 21, 2008 at 6:03 PM, Jay R. Ashworth <jra@...> wrote:

> As soon as I read this, i realize that indeed, you guys are talking
> about "an implementation of an interface to the API", not the actual
> thing itself.
>
> An API, by definition, is a declared set of call and response
> interfaces to a block of core code, with defined parameter domains and
> ranges.
>
> It's not the interfaces you use to *get* to that, be it HTML, REST, or
> whosoever...

When we say "API" we mean "bot API", i.e., "a web-based API provided
for third parties to read data from (and possibly write data to) the
wiki in a programmatic fashion, either anonymously or via a user
account".  This is in context to the human UI, which is meant to
provide the same functions but to humans, not computer programs.  This
is how the term is often used in web contexts these days.

We do *not* mean a programming API, i.e., a set of classes, methods,
and functions that MediaWiki itself and its extensions can call.
That's what we often call the "backend".  api.php uses the backend, as
do the usual index.php and other human access methods.

The issue is that historically, the only access to the backend was
through the human UI, or via extensions (but those can always hack
things up by running queries directly and so on).  Therefore there was
a lot of careless mixing of UI and backend code.  The existence of the
bot API is forcing some of this mixing to be fixed, which incidentally
improves things for extensions too.  So the API is incidentally
related to separation of interface logic from business logic -- but
the API itself is supposed to only contain interface logic, for remote
bot access.

_______________________________________________
Wikitech-l mailing list
Wikitech-l@...
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Bryan Tong Minh]

On Fri, Aug 22, 2008 at 12:01 AM, Roan Kattouw <roan.kattouw@...> wrote:

> Just to clarify again: the API and the UI call *the same functions*, but
> present the results differently. That's why there's *nothing to gain
> whatsoever* in letting the UI call the API.
>
In theory...

_______________________________________________
Wikitech-l mailing list
Wikitech-l@...
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Jim R. Wilson]

> When we say "API" we mean "bot API", i.e., "a web-based API provided
> for third parties to read data from (and possibly write data to) the
> wiki in a programmatic fashion, either anonymously or via a user
> account".

Ok, so under that strict definition, the answer to the original
question of whether the internal core code would ever use it is
obviously "no".  If you define "the API" as including the externalized
HTTP mechanism by which the functionality is accessed, then of course
it makes no sense for core code to use it per all the reasons
previously mentioned.  Case closed, points granted. :)

On the other hand, if you consider the supporting PHP classes through
which api.php makes its calls as part of "the API" then I still
contend that there are probably cases where it would be easier or
simpler (or both) to just use it than say construct all the database
queries onesself.

Personally, I'm not enough of a purist to argue for or against making
"all" core code utilize some standard set of classes to encapsulate a
data model, except to say that there are good reasons why MW doesn't
employ an ORM, and those reasons are probably applicable to the
argument against a one-size-fits-all API backend.

-- Jim

On Thu, Aug 21, 2008 at 5:22 PM, Bryan Tong Minh
<bryan.tongminh@...> wrote:

> On Fri, Aug 22, 2008 at 12:01 AM, Roan Kattouw <roan.kattouw@...> wrote:
>
>> Just to clarify again: the API and the UI call *the same functions*, but
>> present the results differently. That's why there's *nothing to gain
>> whatsoever* in letting the UI call the API.
>>
> In theory...
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l@...
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>

_______________________________________________
Wikitech-l mailing list
Wikitech-l@...
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Nikola Smolenski]

Aryeh Gregor wrote:
> On Thu, Aug 21, 2008 at 2:52 PM, Jim R. Wilson <wilson.jim.r@...> wrote:
>> There are times when utilizing the API programatically could make
>> extension development much easier.  The last time I looked at the API
>
> Although I'm not an extension author, and you are, I don't *think* you
> want to use the API, now or ever.  I think what you want is a clean

As an extension author, I can say that in one of my extensions I have
used the API to great satisfaction of everyone :)

_______________________________________________
Wikitech-l mailing list
Wikitech-l@...
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Roan Kattouw]

Nikola Smolenski schreef:

> Aryeh Gregor wrote:
>  
>> On Thu, Aug 21, 2008 at 2:52 PM, Jim R. Wilson <wilson.jim.r@...> wrote:
>>    
>>> There are times when utilizing the API programatically could make
>>> extension development much easier.  The last time I looked at the API
>>>      
>> Although I'm not an extension author, and you are, I don't *think* you
>> want to use the API, now or ever.  I think what you want is a clean
>>    
>
> As an extension author, I can say that in one of my extensions I have
> used the API to great satisfaction of everyone :)

Using the API internally is useful in some cases, yes. If you're gonna
run a complex query the API happens to support, you're usually better
off using the API, to prevent code duplication. But while there are
bound to be places in the code where the API is used internally (which
doesn't have the HTTP overhead I mentioned earlier, my mistake) in the
core, in extensions and even in the API itself, there's no reason for
the core to systematically use the API for everything.

Roan Kattouw (Catrope)

_______________________________________________
Wikitech-l mailing list
Wikitech-l@...
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Daniel Friesen]

I'm actually working on refactoring the EditPage class.
My goals are a bit different, but they still do require some more
organization in EditPage.

I'm trying to make EditPage expendable. Currently the EditPage has so
much different stuff mixed in different areas of the class that it's
impossible to override a small area of it inside of a subclass. ie: A
different type of edit page, such as SF's formedit.

~Daniel Friesen(Dantman, Nadir-Seen-Fire) of:
-The Nadir-Point Group (http://nadir-point.com)
--It's Wiki-Tools subgroup (http://wiki-tools.com)
--The ElectronicMe project (http://electronic-me.org)
--Games-G.P.S. (http://ggps.org)
-And Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG)
--Animepedia (http://anime.wikia.com)
--Narutopedia (http://naruto.wikia.com)



Brion Vibber wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Aryeh Gregor wrote:
>  
>> On Wed, Aug 20, 2008 at 2:20 PM, Roan Kattouw <roan.kattouw@...> wrote:
>>    
>>> About enabling the edit API on Wikipedia: I think it's ready to go. The
>>> only real problem it currently has is that action=edit doesn't handle
>>> aborts by hooks too well; the edit will be aborted, but the client will
>>> only get a vague "A hook aborted the action" (or something along those
>>> lines) error. A hook that allows for aborting the edit with a meaningful
>>> error message has been added (APIEditBeforeSave), but AFAIK it's
>>> currently only used by ConfirmEdit (and only because I migrated it
>>> myself). Similarly, extensions influencing other actions may rely on UI
>>> hooks that the API bypasses altogether.
>>>      
>> Um, why are you adding an API-specific hook for this?  Shouldn't it be
>> a backend hook?  I'm not sure why there should be *any* API hooks,
>> actually, since the API should just be presenting backend information
>> in a standard format.  Extensions should never want to change the
>> format that's returned, as far as I can imagine, since it's supposed
>> to be uniform across all wikis.  They should only want to change the
>> actual info, which should be done on the backend level.
>>    
>
> The way it _should_ be working is something like this:
>
> 1) There's a backend ("controller") class for performing edits. This has
> hook points for things like aborting or altering edits (spam checks,
> captcha, etc)
>
> 2) There's a frontend ("view") class for handling the HTML edit form.
> This has hook points for customizing the form output, checking custom
> input, and presenting UI for error conditions ("you hit spam!" or "you
> need to submit this extra form")
>
> 3) There's another frontend ("view") class for handling the API's edit
> interface. This _might_ also have hook points for handling special
> input/output and custom error formatting, though _ideally_ such stuff
> should be able to use existing I/O channels specified in the API (spam
> hit just raises an error conditions; captcha hits have an existing
> channel for saying "show this and respond to it").
>
>
> Currently the EditPage class mixes a fair chunk of backend and UI, as do
> the edit filter hooks for spam blacklisting, CAPTCHAs, etc, so it's a
> bit icky. There's been some refactoring in the course of creating the
> edit API (as there was much refactoring to Special:Userlogin when the
> API's login modules were being created), but it remains incomplete.
>
> (At least the raw page data storage model isn't mixed into EditPage! :)
>
> - -- brion
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkisaV8ACgkQwRnhpk1wk47AswCgxnUPZhA5+Kxg0tuGdxJ0Z19q
> SIEAoKNhI5/SCjIE8tqDPmPTGprwmcW8
> =nPgB
> -----END PGP SIGNATURE-----
>  

_______________________________________________
Wikitech-l mailing list
Wikitech-l@...
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Roan Kattouw]

Daniel Friesen schreef:
> I'm actually working on refactoring the EditPage class.
> My goals are a bit different, but they still do require some more
> organization in EditPage.
>
> I'm trying to make EditPage expendable. Currently the EditPage has so
> much different stuff mixed in different areas of the class that it's
> impossible to override a small area of it inside of a subclass. ie: A
> different type of edit page, such as SF's formedit.
>  
If that results in a clean separation of UI and backend code, it would
probably solve my problem.

Roan Kattouw (Catrope)

_______________________________________________
Wikitech-l mailing list
Wikitech-l@...
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Daniel Friesen]

;) And then there are a few of us who get intimate with a fair percent
of the complex and isolated interfaces, enough to scare themselves.
T_T Some time ago, I came to realize that I had actually started to
grasp an understanding of how the Parser worked. The preprocessor as
well. Nearly all my new ParserFunctions use SFH_OBJ_ARGS and some even
do scary things with the frames. When someone asks what function to use
in a hook or a tag to do something with the parser, I actually
understand what part of the parser will best do that for them (Without
needing to trudge around the functions and make a bad guess), and even
worse... T_T I'm actually rewriting a portion of the parser myself...
And I'm starting to make use of parseresque code in my own work.

As for the other, anyone remember my rewrite of the Database class's
titleName method. And my suggestion for a doQuery arg (though that was
changed into a backend function that works with strings).

Actually, I'm building my own Database library. Heh, now that's the
scary portion. I even implemented Brion's idea for a RawSql class (
Trust me ;) it works quite nicely, it even inspired the RawMarkup class
inside of my markup abstraction library (similar to the Xml class))

~Daniel Friesen(Dantman, Nadir-Seen-Fire) of:
-The Nadir-Point Group (http://nadir-point.com)
--It's Wiki-Tools subgroup (http://wiki-tools.com)
--The ElectronicMe project (http://electronic-me.org)
--Games-G.P.S. (http://ggps.org)
-And Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG)
--Animepedia (http://anime.wikia.com)
--Narutopedia (http://naruto.wikia.com)

Roan Kattouw wrote:

> Aryeh Gregor schreef:
>  
>> On Wed, Aug 20, 2008 at 3:24 PM, Jay R. Ashworth <jra@...> wrote:
>>  
>>    
>>> So the obvious followup question is: is there a plan to migrate the
>>> front end to *use the API* to talk to the backend (which is the
>>> preferred approach to such things anyway)?
>>>    
>>>      
>> One practical issue with this at present is that nobody who does much
>> of anything with core does much of anything with the API.  I've barely
>> looked at it at all.
>>  
>>    
> True. Actually, there's a pattern of isolation here. While pretty much
> all developers are familiar with the 'core' classes (Title, Article,
> Revision, etc.), very few are familiar with isolated ones such as the
> parser, the API, the image handling code, the Database abstraction layer
> (except for select() and similar functions)
>  
>> As a more philosophical thing, there's no reason for the human UI to
>> call the API.  We should have a back-end, and then two interfaces to
>> that: one designed for external robots, and one designed for
>> HTML-viewing humans.  Both of the interfaces should use the internal
>> PHP interface to speak to the back-end.  The API operates in a format
>> that's suitable for robots to use, not suitable for internal code to
>> use.
>>    
> Simetrical is right here: the UI and the API call the same functions,
> and display the results in different ways. That's exactly why there's no
> sense in migrating the front end to the API (and that's just forgetting
> about the HTTP overhead involved).
>
> Roan Kattouw (Catrope)
>  

_______________________________________________
Wikitech-l mailing list
Wikitech-l@...
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Roan Kattouw]

Daniel Friesen schreef:

> ;) And then there are a few of us who get intimate with a fair percent
> of the complex and isolated interfaces, enough to scare themselves.
> T_T Some time ago, I came to realize that I had actually started to
> grasp an understanding of how the Parser worked. The preprocessor as
> well. Nearly all my new ParserFunctions use SFH_OBJ_ARGS and some even
> do scary things with the frames. When someone asks what function to use
> in a hook or a tag to do something with the parser, I actually
> understand what part of the parser will best do that for them (Without
> needing to trudge around the functions and make a bad guess), and even
> worse... T_T I'm actually rewriting a portion of the parser myself...
> And I'm starting to make use of parseresque code in my own work.
>
> As for the other, anyone remember my rewrite of the Database class's
> titleName method. And my suggestion for a doQuery arg (though that was
> changed into a backend function that works with strings).
>
> Actually, I'm building my own Database library. Heh, now that's the
> scary portion. I even implemented Brion's idea for a RawSql class (
> Trust me ;) it works quite nicely, it even inspired the RawMarkup class
> inside of my markup abstraction library (similar to the Xml class))
>  

You're welcome to help out us API devs, if that's your next step ;)

Roan Kattouw (Catrope)

_______________________________________________
Wikitech-l mailing list
Wikitech-l@...
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Daniel Friesen]

It might do a bit of a better job of it. I'm actually thinking of
putting the preview parsing stuff (just the parserOutput) into the
initialization rather than arbitrarily calling a function which mixes UI
and other stuff.

Though, I may be doing a bit more work in the UI area than a simple UI
backend split. I'm actually splitting up the different areas of the UI
so that parts can actually be overrided rather than needing to override
and duplicate an entire large function in a way which may cause issues
when some of that code is changed in future revisions.

~Daniel Friesen(Dantman, Nadir-Seen-Fire) of:
-The Nadir-Point Group (http://nadir-point.com)
--It's Wiki-Tools subgroup (http://wiki-tools.com)
--The ElectronicMe project (http://electronic-me.org)
--Games-G.P.S. (http://ggps.org)
-And Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG)
--Animepedia (http://anime.wikia.com)
--Narutopedia (http://naruto.wikia.com)

Roan Kattouw wrote:

> Daniel Friesen schreef:
>  
>> I'm actually working on refactoring the EditPage class.
>> My goals are a bit different, but they still do require some more
>> organization in EditPage.
>>
>> I'm trying to make EditPage expendable. Currently the EditPage has so
>> much different stuff mixed in different areas of the class that it's
>> impossible to override a small area of it inside of a subclass. ie: A
>> different type of edit page, such as SF's formedit.
>>  
>>    
> If that results in a clean separation of UI and backend code, it would
> probably solve my problem.
>
> Roan Kattouw (Catrope)
>  

_______________________________________________
Wikitech-l mailing list
Wikitech-l@...
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Daniel Friesen]

Heh, perhaps... ^_^ Though I'm more likely to do some DB+API evil and
attempt to eliminate all the hardcoded SQL inside of the API.

Though, to say the truth I don't know how well I'd fit in the API. I
honestly have a strong dislike of supporting real old things. While I do
try to keep backwards compatibility in the rest of MediaWiki, there are
many cases where where we break things for the extensions that interact
with the software.
When it comes to my extensions that's a whole strong case. I only
support alpha and the latest stable (well, 1.13 came out, so I might
support 1.12 for a few more months). Actually I have a few real complex
extensions which only support recent versions of 1.14a, but of course
those are special cases using real extreme parts of the parser which
I've actually had to add to the parser myself.
But really, one of my old morales was "Upgrades are for features and
fixes... If you want features, then upgrade. There is no reason to
support a new feature in an old version of the software. If someone
wants the feature, then they can upgrade. It is the same software, it
merely has a different version number and more features."

^_^ Actually, on an unrelated note... I wish I'd stop seeing these
/extensions/.../install.php files. Does anyone not remember that we have
a hook inside of update.php which allows extensions to add new SQL
updates into the update system? ;)

~Daniel Friesen(Dantman, Nadir-Seen-Fire) of:
-The Nadir-Point Group (http://nadir-point.com)
--It's Wiki-Tools subgroup (http://wiki-tools.com)
--The ElectronicMe project (http://electronic-me.org)
--Games-G.P.S. (http://ggps.org)
-And Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG)
--Animepedia (http://anime.wikia.com)
--Narutopedia (http://naruto.wikia.com)

Roan Kattouw wrote:

> Daniel Friesen schreef:
>  
>> ;) And then there are a few of us who get intimate with a fair percent
>> of the complex and isolated interfaces, enough to scare themselves.
>> T_T Some time ago, I came to realize that I had actually started to
>> grasp an understanding of how the Parser worked. The preprocessor as
>> well. Nearly all my new ParserFunctions use SFH_OBJ_ARGS and some even
>> do scary things with the frames. When someone asks what function to use
>> in a hook or a tag to do something with the parser, I actually
>> understand what part of the parser will best do that for them (Without
>> needing to trudge around the functions and make a bad guess), and even
>> worse... T_T I'm actually rewriting a portion of the parser myself...
>> And I'm starting to make use of parseresque code in my own work.
>>
>> As for the other, anyone remember my rewrite of the Database class's
>> titleName method. And my suggestion for a doQuery arg (though that was
>> changed into a backend function that works with strings).
>>
>> Actually, I'm building my own Database library. Heh, now that's the
>> scary portion. I even implemented Brion's idea for a RawSql class (
>> Trust me ;) it works quite nicely, it even inspired the RawMarkup class
>> inside of my markup abstraction library (similar to the Xml class))
>>  
>>    
> You're welcome to help out us API devs, if that's your next step ;)
>
> Roan Kattouw (Catrope)
>  

_______________________________________________
Wikitech-l mailing list
Wikitech-l@...
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Roan Kattouw]

Daniel Friesen schreef:
> Heh, perhaps... ^_^ Though I'm more likely to do some DB+API evil and
> attempt to eliminate all the hardcoded SQL inside of the API.
>  
Save your time, it's been eliminated already AFAIK.
> Though, to say the truth I don't know how well I'd fit in the API. I
> honestly have a strong dislike of supporting real old things. While I do
> try to keep backwards compatibility in the rest of MediaWiki, there are
> many cases where where we break things for the extensions that interact
> with the software.
>  
Hearing that, the idea of having you as API lead developer does sound
scary (no offense).

Roan Kattouw (Catrope)

_______________________________________________
Wikitech-l mailing list
Wikitech-l@...
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Aryeh Gregor]

On Fri, Aug 22, 2008 at 2:02 AM, Jim R. Wilson <wilson.jim.r@...> wrote:
> On the other hand, if you consider the supporting PHP classes through
> which api.php makes its calls as part of "the API" then I still
> contend that there are probably cases where it would be easier or
> simpler (or both) to just use it than say construct all the database
> queries onesself.

Those are what I'm calling the "backend", which is supposed to be
called separately by both the human UI and the bot API.  As well as
any extensions.

On Fri, Aug 22, 2008 at 2:51 AM, Nikola Smolenski <smolensk@...> wrote:
> As an extension author, I can say that in one of my extensions I have
> used the API to great satisfaction of everyone :)

Which one?

On Fri, Aug 22, 2008 at 4:40 AM, Roan Kattouw <roan.kattouw@...> wrote:
> Using the API internally is useful in some cases, yes. If you're gonna
> run a complex query the API happens to support, you're usually better
> off using the API, to prevent code duplication.

So why does the API have any logic to do anything except translate the
HTTP query into backend functions and display the results?  If you
have a lot of internal logic anywhere, that other callers would like
to use, I suspect that would be best moved into the actual classes
somehow.  It's the same as with the human UI: you shouldn't (ideally)
be mixing business logic with logic for a specific output type.

_______________________________________________
Wikitech-l mailing list
Wikitech-l@...
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Nikola Smolenski]

Aryeh Gregor wrote:
> On Fri, Aug 22, 2008 at 2:51 AM, Nikola Smolenski <smolensk@...> wrote:
>> As an extension author, I can say that in one of my extensions I have
>> used the API to great satisfaction of everyone :)
>
> Which one?

http://www.mediawiki.org/wiki/Extension:Interlanguage

_______________________________________________
Wikitech-l mailing list
Wikitech-l@...
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Roan Kattouw]

Aryeh Gregor schreef:

> On Fri, Aug 22, 2008 at 4:40 AM, Roan Kattouw <roan.kattouw@...> wrote:
>  
>
>> Using the API internally is useful in some cases, yes. If you're gonna
>> run a complex query the API happens to support, you're usually better
>> off using the API, to prevent code duplication.
>>    
>
> So why does the API have any logic to do anything except translate the
> HTTP query into backend functions and display the results?  If you
> have a lot of internal logic anywhere, that other callers would like
> to use, I suspect that would be best moved into the actual classes
> somehow.  It's the same as with the human UI: you shouldn't (ideally)
> be mixing business logic with logic for a specific output type.

That's probably laziness caused by the fact that the API implementation
predates the code that uses FauxRequest.

Roan Kattouw (Catrope)

_______________________________________________
Wikitech-l mailing list
Wikitech-l@...
https://lists.wikimedia.org/mailman/listinfo/wikitech-l