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
