JSON/AJAX services

[Elias Torres <el...@torrez.us>]

While I receive some feedback on tagging summaries, I wanted to go ahead
and start the discussion on the auto-complete feature for tags as well.

I need to add a servlet to get all the tags for a given website based on
on tag prefix.

i.e. /roller-ui/authoring/ajax/tags/r

would return in some JSON format.

roller
roll
...

Allen had previously suggested to unify these and I'd agree. His
suggestions were these:

/roller-ui/authoring/ajax/users (info about users)
/roller-ui/authoring/ajax/tags (info about tags)


Mine are:

/roller-services/json/users/
/roller-services/json/tags/

My rationale is that other clients might use this information such as
blogs and they are not necessarily attached to our authoring
environment. Allen had suggested we re-purposed AAPP but he's right that
there might security concerns because you can change the database
through those.

-Elias

Re: JSON/AJAX services

[Allen Gilliland <al...@sun.com>]

Elias Torres wrote:
> 
> Allen Gilliland wrote:
>>
>> Elias Torres wrote:
>>> While I receive some feedback on tagging summaries, I wanted to go ahead
>>> and start the discussion on the auto-complete feature for tags as well.
>> Before talking about the implementation I would first say that while I
>> think it's nice that we have a tag auto-complete feature available, I
>> don't think it's required.  I would focus on getting the core tagging
>> functionality done first before spending time on this because at the end
>> of the day this auto-complete feature only makes it a little bit easier
>> on users when choosing tag names, but they can get by just fine without it.
> 
> I agree on waiting. I just was throwing this question so when it's time
> to do it we have a consensus on the URL/access.

sounds good.


> 
>>
>>> I need to add a servlet to get all the tags for a given website based on
>>> on tag prefix.
>>>
>>> i.e. /roller-ui/authoring/ajax/tags/r
>>>
>>> would return in some JSON format.
>>>
>>> roller
>>> roll
>>> ...
>>>
>>> Allen had previously suggested to unify these and I'd agree. His
>>> suggestions were these:
>>>
>>> /roller-ui/authoring/ajax/users (info about users)
>>> /roller-ui/authoring/ajax/tags (info about tags)
>>>
>>>
>>> Mine are:
>>>
>>> /roller-services/json/users/
>>> /roller-services/json/tags/
>>>
>>> My rationale is that other clients might use this information such as
>>> blogs and they are not necessarily attached to our authoring
>>> environment. Allen had suggested we re-purposed AAPP but he's right that
>>> there might security concerns because you can change the database
>>> through those.
>> I don't care about the json vs. ajax in the url, but there needs to be a
>> broader discussion about how we want to deal with these urls which are
>> basically web service urls.
>>
>> I like the idea of exposing them for anyone to use, but there is a
>> definite risk involved in that.  For the users endpoint I don't think
>> I'm comfortable exposing that publicly because it offers up both
>> usernames and email addresses and that could be used very maliciously by
>> someone if they wanted to.
> 
> UserData service can always require authentication but I still would
> like to see it outside of the authoring path.

okay, i am fine with that.


> 
>> I don't think the tags has any security implications, but it definitely
>> has performance implications.  We haven't really heard much about
>> tagging performance so far and I am currently weary of any operation
>> which will be done against the entire tag set and not constrained at
>> least to a single weblog.  If that is exposed to users and they start to
>> use it on weblogs which generate lots of traffic it could become
>> problematic, so we would need a way to control this a bit.
> 
> 
> The query will be very simple. It'd be against the aggregate table and
> would be either against a specific site's tag or against the tags with
> website = NULL. We will force at least one character so we are talking
> about a query like this:
> 
> select name, count from websitetagagg where website = ? and name like 'a%'.
> 
> The max number of rows will be the distinct number of tags for a website
>  or the NULL website. We are normalizing somewhat the tag names. Anybody
> else has the opposite intuition on the query performance?

sorry, my mind is wandering a bit today.  you are correct, that 
shouldn't cause any issues.

the urls you chose are fine with me as well.

-- Allen


> 
> -Elias
> 
>> -- Allen
>>
>>
>>> -Elias

Re: JSON/AJAX services

[Elias Torres <el...@torrez.us>]

Allen Gilliland wrote:
> 
> 
> Elias Torres wrote:
>> While I receive some feedback on tagging summaries, I wanted to go ahead
>> and start the discussion on the auto-complete feature for tags as well.
> 
> Before talking about the implementation I would first say that while I
> think it's nice that we have a tag auto-complete feature available, I
> don't think it's required.  I would focus on getting the core tagging
> functionality done first before spending time on this because at the end
> of the day this auto-complete feature only makes it a little bit easier
> on users when choosing tag names, but they can get by just fine without it.

I agree on waiting. I just was throwing this question so when it's time
to do it we have a consensus on the URL/access.

> 
> 
>>
>> I need to add a servlet to get all the tags for a given website based on
>> on tag prefix.
>>
>> i.e. /roller-ui/authoring/ajax/tags/r
>>
>> would return in some JSON format.
>>
>> roller
>> roll
>> ...
>>
>> Allen had previously suggested to unify these and I'd agree. His
>> suggestions were these:
>>
>> /roller-ui/authoring/ajax/users (info about users)
>> /roller-ui/authoring/ajax/tags (info about tags)
>>
>>
>> Mine are:
>>
>> /roller-services/json/users/
>> /roller-services/json/tags/
>>
>> My rationale is that other clients might use this information such as
>> blogs and they are not necessarily attached to our authoring
>> environment. Allen had suggested we re-purposed AAPP but he's right that
>> there might security concerns because you can change the database
>> through those.
> 
> I don't care about the json vs. ajax in the url, but there needs to be a
> broader discussion about how we want to deal with these urls which are
> basically web service urls.
> 
> I like the idea of exposing them for anyone to use, but there is a
> definite risk involved in that.  For the users endpoint I don't think
> I'm comfortable exposing that publicly because it offers up both
> usernames and email addresses and that could be used very maliciously by
> someone if they wanted to.

UserData service can always require authentication but I still would
like to see it outside of the authoring path.

> 
> I don't think the tags has any security implications, but it definitely
> has performance implications.  We haven't really heard much about
> tagging performance so far and I am currently weary of any operation
> which will be done against the entire tag set and not constrained at
> least to a single weblog.  If that is exposed to users and they start to
> use it on weblogs which generate lots of traffic it could become
> problematic, so we would need a way to control this a bit.


The query will be very simple. It'd be against the aggregate table and
would be either against a specific site's tag or against the tags with
website = NULL. We will force at least one character so we are talking
about a query like this:

select name, count from websitetagagg where website = ? and name like 'a%'.

The max number of rows will be the distinct number of tags for a website
 or the NULL website. We are normalizing somewhat the tag names. Anybody
else has the opposite intuition on the query performance?

-Elias

> 
> -- Allen
> 
> 
>>
>> -Elias
> 

Re: JSON/AJAX services

[Allen Gilliland <Al...@Sun.COM>]

Elias Torres wrote:
> While I receive some feedback on tagging summaries, I wanted to go ahead
> and start the discussion on the auto-complete feature for tags as well.

Before talking about the implementation I would first say that while I 
think it's nice that we have a tag auto-complete feature available, I 
don't think it's required.  I would focus on getting the core tagging 
functionality done first before spending time on this because at the end 
of the day this auto-complete feature only makes it a little bit easier 
on users when choosing tag names, but they can get by just fine without it.


> 
> I need to add a servlet to get all the tags for a given website based on
> on tag prefix.
> 
> i.e. /roller-ui/authoring/ajax/tags/r
> 
> would return in some JSON format.
> 
> roller
> roll
> ...
> 
> Allen had previously suggested to unify these and I'd agree. His
> suggestions were these:
> 
> /roller-ui/authoring/ajax/users (info about users)
> /roller-ui/authoring/ajax/tags (info about tags)
> 
> 
> Mine are:
> 
> /roller-services/json/users/
> /roller-services/json/tags/
> 
> My rationale is that other clients might use this information such as
> blogs and they are not necessarily attached to our authoring
> environment. Allen had suggested we re-purposed AAPP but he's right that
> there might security concerns because you can change the database
> through those.

I don't care about the json vs. ajax in the url, but there needs to be a 
broader discussion about how we want to deal with these urls which are 
basically web service urls.

I like the idea of exposing them for anyone to use, but there is a 
definite risk involved in that.  For the users endpoint I don't think 
I'm comfortable exposing that publicly because it offers up both 
usernames and email addresses and that could be used very maliciously by 
someone if they wanted to.

I don't think the tags has any security implications, but it definitely 
has performance implications.  We haven't really heard much about 
tagging performance so far and I am currently weary of any operation 
which will be done against the entire tag set and not constrained at 
least to a single weblog.  If that is exposed to users and they start to 
use it on weblogs which generate lots of traffic it could become 
problematic, so we would need a way to control this a bit.

-- Allen


> 
> -Elias