[ghns] ghns status, api, etc.

[Jeremy Whiting]

On Wednesday 24 June 2009 15:50:45 Frank Karlitschek wrote:
> On 24.06.2009, at 21:02, Josef Spillner wrote:
> > Am Mittwoch, 24. Juni 2009 20:44:06 schrieb Jeremy Whiting:
> >> I can think of one other way to do this.  The client could ask the
> >> server
> >> for a custom feed and give the server all the entry id's it would
> >> like in
> >> the feed in the http headers. then get one feed back containing all
> >> the
> >> entry information for the requested entries.  That would only
> >> require one
> >> http request that way.  What do you think of that?
> >
> > Sounds good to me and should work up to any reasonable number of
> > installed
> > entries. I've thought also about identified (authenticated) users
> > but this
> > would trade anonymity for performance, so your suggestion is
> > obviously better,
> > even though the system security is slightly worse off when small
> > requests are
> > meeting huge replies.
> > The world is full of trade-offs, we can't have the ultimate system :)
> >
> >
> > Josef
>
> Well. This is possible.
> The problem with this solution is that we need a specific API call for
> this which means additional complexity which is always evil.
> But the bigger problem is that the result of the API call wouldn´t be
> cacheable on the server side because the collection of entries to
> check is quite unique for a specific user. So I have to do a lot of
> expensive calculations on the server.
>
>
> I would prefere if you simple call the existing content-get method
> which gives you the version of the entry.
> This call is very good cachable. I can use an unlimited cache time for
> the entry and simple exire the cache if the developer updates the
> content entry. This would give ma a nearly 100% cache hitrate and zero
> database load.
>
> It´s true that this approach would require more API calls. But the
> calls are much more cheaper than the suggested call.
>
>  From my experience the server load is the limiting scalability
> resource and not the bandwidth on the client. The amount of transfered
> data is not a lot even with my approach.
>
> What do you think?

I agree that this makes more sense. I think it might highlight a difference 
between the soap and REST protocols though in REST's favor since smaller http 
headers are used for each request, right?

Jeremy

>
>
> Cherrs
> Frank
>
>
>
> --
> Frank Karlitschek
> karlitschek at kde.org
>
>
>
>
> _______________________________________________
> ghns mailing list
> ghns at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/ghns