On 11/25/2009 08:34 PM, Bryan Call wrote:
I am talking about internal files created by traffic server, cache and hostdb
being a couple of them. For someone with a large setup they would roll out
software to a few servers at a time. Most caches have a Zipfian distribution
and would have a wo
libev based polling infrastructure
--
Key: TS-49
URL: https://issues.apache.org/jira/browse/TS-49
Project: Traffic Server
Issue Type: New Feature
Reporter: Paul Querna
prototype of using libev to
On Nov 25, 2009, at 3:32 PM, Leif Hedstrom wrote:
> On 11/25/2009 03:51 PM, Bryan Call wrote:
>> We also need to worry about stability too. We have a lot of changes in the
>> tree that are untested and we don't have any automated testing to verify all
>> the changes we have already made to the
I have to agree that there are definitely bigger fish to fry. High on
my list
is making range requests and large files fast which means changing the
cache structure
a bit which should be done before the release. I'd rather concentrate
on that
and just try to ensure that the existing C API is
Ditto. Can any C++ zealots please stand up? ;-)
-Original Message-
From: Leif Hedstrom [mailto:zw...@apache.org]
Sent: Wednesday, November 25, 2009 3:53 PM
To: trafficserver-dev@incubator.apache.org
Subject: Re: C++ version of InkAPI ?
On 11/25/2009 04:32 PM, Leif Hedstrom wrote:
>
>
>
On 11/25/2009 04:32 PM, Leif Hedstrom wrote:
I'd suggest we come up with a list of the requirements for what needs
to be done in the "2.x" branch, and then freeze it. I'd be hard to
convince that addressing the issues listed above is not one of those
requirements :).
I should say, changing
On 11/25/2009 03:51 PM, Bryan Call wrote:
We also need to worry about stability too. We have a lot of changes in the
tree that are untested and we don't have any automated testing to verify all
the changes we have already made to the Apache tree don't have any hidden gems
(bugs). There has t
We also need to worry about stability too. We have a lot of changes in the
tree that are untested and we don't have any automated testing to verify all
the changes we have already made to the Apache tree don't have any hidden gems
(bugs). There has to be a balance with breaking compatibility m
Personally I like C APIs, they seem to be easier to maintain. I was once force
to implement an API using pure virtuals and it was hell dealing with binary
compatibility breaking all the time (well hell for the people using the API :)).
Yes, the internal objects can be whatever you want. That i
On 11/25/2009 03:12 PM, John Plevyak wrote:
Good point. So non-virtual functions which would imply wrapper objects
for internal objects with virtual functions. I wonder if there are any
tools to automate that.
Sigh. This is getting complicated. C++ is a pain. Makes me think
the C API isn't
Good point. So non-virtual functions which would imply wrapper objects
for internal objects with virtual functions. I wonder if there are any
tools to automate that.
Sigh. This is getting complicated. C++ is a pain. Makes me think the
C API isn't so bad.
john
Bryan Call wrote:
Have pure
I agree with everything you are saying except that I think there is
value from
a simple C++ interface of just abstract classes with virtual functions and
perhaps a few exposed instance variables for very stable common objects.
The reason is that the internals are modeled that way and most plugi
Have pure virtuals ties us into not being able to expand the API for the
class without breaking binary compatibility. I would rather see a
private implementation design for the API instead. That way if we want
to expand the API to add functionality it won't break binary compatibility.
-Bryan
Maybe it depends what kind of plugins you're talking about.
Simple header munging (a la output-header.c) is simple(-ish)
almost no matter what; boilerplate is boilerplate. Realistically,
people will just cut & paste from samples (thanks Chris).
A really complex plugin -- say, analyze the payloa
(adding d...@httpd cc)
On Tue, Nov 24, 2009 at 10:20 AM, Miles Libbey wrote:
> Hi folks-
> We have a volunteer to translate our documentation from English into Korean.
> Any recommendations for translation management/infrastructure? That is-- as
> the english documentation changes, is there any
Given that the existing C API is often a wrapper on an internal C++ API,
there is a natural
mapping of just using the existing internal C++ APIs as the InkAPI but just
convert them to be pure virtual. This would also encourage clean internal
APIs to make it easier to use for the InkAPI. I a
On 11/25/2009 11:43 AM, John Plevyak wrote:
<< transfer from IRC>>
Here is a proposal:
1. C++ APIs
2. Clean SWIG for supporting other language
(in other words, the C++ APIs would have to work well with SWIG)
Open question: do we expose some very stable data structures, e.g.
IOBuffer, VI
<< transfer from IRC>>
Here is a proposal:
1. C++ APIs
2. Clean SWIG for supporting other language
(in other words, the C++ APIs would have to work well with SWIG)
Open question: do we expose some very stable data structures, e.g.
IOBuffer, VIO ?
John Plevyak wrote:
Has any thought
Has any thought been given to a C++ version of the InkAPI?
The current InkAPI includes "bool" so it doesn't even compile with C
which implies to me that most folks are using C++ already.
Dynamic loading with C++ is only a bit trickier and the resulting interface
would match the implementation a
Many projects are using cwiki.apache.org/confluence to maintain
documentation. Confluence has version tracking with visual diff
display. Probably also possible to setup an RSS feed to watch the
pages that changed. So that should be all you need.
Andrus
On Nov 24, 2009, at 8:20 PM, Miles Li
On Wed, Nov 25, 2009 at 2:20 AM, Miles Libbey wrote:
> Hi folks-
> We have a volunteer to translate our documentation from English into Korean.
> Any recommendations for translation management/infrastructure? That is-- as
> the english documentation changes, is there any software that can help to
21 matches
Mail list logo
