Re: [questions] Which jakartaEE version we plan for pulsar 3.0.0?

[Zixuan Liu]

Sounds greate that migrating to jersey 3.x from jersey 2.x.

Thanks,
Zixuan

ZhangJian He  于2023年2月25日周六 11:01写道：

> Hello, community. I want to know Which jakartaEE version we plan for pulsar
> 3.0.0. Now we use jersey 2.x, which uses Jakarta EE8.
>
> Maybe we will need to update the jersey.
> Eclipse Jersey (eclipse-ee4j.github.io)
> 
> 2.x is for Jakarta EE8. 3.0.x is for Jakarta EE9 and 3.1.x is for Jakarta
> EE10.
>
> Thank you for your time and consideration.
>
> Thanks
> ZhangJian He
>

Re: Introducer Pulsar admin api to pulsar-client-go

[Zixuan Liu]

> I would like to suggest creating a new repository called "pulsar-admin-go"

+1, I agreed with you.

Thanks,
Zixuan

ZhangJian He  于2023年2月25日周六 11:05写道：

> Following our previous discussions via email, I would like to suggest
> creating a new repository called "pulsar-admin-go". This repository will
> serve as a platform for all of us to contribute our code. Pulsarctl[0] go
> first.
>
> Please let me know your thoughts on this matter.
>
> [0] - https://github.com/streamnative/pulsarctl
>
> Thanks
> ZhangJian He
>
>
> On Fri, 17 Feb 2023 at 23:24, ZhangJian He  wrote:
>
> > Thank for StreamNative for willing to donate this project. This means we
> > don't have to develop and maintain a set of HTTP code from scratch. My
> idea
> > aligns with Yunze's, and separating it into a standalone pulsar-admin-go
> > project would be better. The **pulsarctl** repo contains bookkeeper http
> > call too. Maybe we can have a project bookkeeper-admin-go ?（it's a liitle
> > going off-topic ）
> >
> > Thanks
> > ZhangJian He
> >
> >
> > On Fri, 17 Feb 2023 at 20:29, PengHui Li 
> wrote:
> >
> >> Hi Yunze,
> >>
> >> Yes, we can split it.
> >> Both one repo with two modules or two repos works for me.
> >>
> >> The pulsarctl already have the admin API and CLI.
> >> So I think we don’t need to develop another one.
> >>
> >> Best,
> >> Penghui
> >>
> >> > On Feb 17, 2023, at 17:44, Yunze Xu 
> >> wrote:
> >> >
> >> > Hi PengHui,
> >> >
> >> > Now I changed my mind a bit. Even if the pulsarctl was contributed to
> >> > the Apache Foundation, I think we should also avoid adding it as the
> >> > dependency. What we need is an API layer but not the CLI, while
> >> > pulsarctl couples the API and CLI.
> >> >
> >> > At the moment, my expectation is:
> >> > 1. Use a separate repo (e.g. pulsar-admin-go) to implement the admin
> >> > APIs in Golang.
> >> > 2. Depend this new repo in pulsarctl.
> >> >
> >> > Then we will have three Go projects:
> >> > - pulsar-client-go: The Pulsar Go client APIs
> >> > - pulsar-admin-go: The Pulsar Go admin APIs
> >> > - pulsarctl: The admin CLI tool written in Go
> >> >
> >> > Thanks,
> >> > Yunze
> >> >
> >> > On Fri, Feb 17, 2023 at 4:22 PM PengHui Li 
> wrote:
> >> >>
> >> >> I checked with Sijie today.
> >> >> StreamNative can contribute the pulsarctl project to Apache
> Foundation.
> >> >>
> >> >> Regards,
> >> >> Penghui
> >> >>
> >> >> On Fri, Feb 17, 2023 at 4:02 PM Enrico Olivelli  >
> >> wrote:
> >> >>
> >> >>> I agree to add an admin API to the go client, this would be very
> >> helpful.
> >> >>>
> >> >>> Il giorno ven 17 feb 2023 alle ore 08:44 Zixuan Liu
> >> >>>  ha scritto:
> >> 
> >>  Hi Zhangjian,
> >> 
> >>  This is a good idea to write the admin client by golang, but I
> don't
> >>  suggest add the admin features to pulsar-go-client, it's better to
> >> use a
> >>  new repository to do that to  separate dependencies.
> >> 
> >>  BTW, StreamNative has a pulsarctl [0] tool, which includes the
> admin
> >> api.
> >> 
> >> >> It's better to reuse existing code rather than reinventing the
> >> wheel.
> >> 
> >>  I aggred this point. If possible, we can integrate the pulsarctl to
> >> this
> >>  new project.
> >> >>>
> >> >>> We are talking about adding a client that calls a
> >> >>> well defined and maintained REST API.
> >> >>> It is better to have our implementation and not rely on third
> parties
> >> >>> when it is possible.
> >> >>> If there is a security issue in pulsarctl, how would we handle that
> ?
> >> >>> Also the Pulsar community maintains the Pulsar API and this is the
> >> >>> place where it is easier to keep the client up-to-date with the new
> >> >>> APIs that we will develop,
> >> >>> we can't wait for a third party project to implement our own APIs
> and
> >> >>> wait for an upgrade (even if it is OSS, we cannot cut releases or
> have
> >> >>> control over the release cycle)
> >> >>>
> >> >>>
> >> >>> Enrico
> >> >>>
> >> >>>
> >> >>>
> >> 
> >>  [0] - https://github.com/streamnative/pulsarctl
> >> 
> >>  Thanks,
> >>  Zixuan
> >> 
> >> 
> >>  ZhangJian He  于2023年2月17日周五 13:47写道：
> >> 
> >> > Separating dependencies is better. For example, I think
> >> >>> Pulsar-admin-go can
> >> > only have golang standard tls and http dependencies.
> >> > But it seems impossible to have two go modules when publishing
> >> packages
> >> > using github.
> >> >
> >> >> Has anyone tried generating an admin client from our generated
> open
> >> > api spec?
> >> >
> >> > I have attempted it, but it requires us to modify our Swagger
> file.
> >> Our
> >> > existing Swagger file can't generate HTTP clients directly.
> Perhaps
> >> we
> >> >>> can
> >> > rewrite a unified and standardized Swagger file, and then generate
> >> all
> >> > code, including brokers, from there gradually.
> >> >
> >> > Thanks
> >> > ZhangJian He
> >> >
> >> >
> 

Re: Introducer Pulsar admin api to pulsar-client-go

[ZhangJian He]

Following our previous discussions via email, I would like to suggest
creating a new repository called "pulsar-admin-go". This repository will
serve as a platform for all of us to contribute our code. Pulsarctl[0] go
first.

Please let me know your thoughts on this matter.

[0] - https://github.com/streamnative/pulsarctl

Thanks
ZhangJian He


On Fri, 17 Feb 2023 at 23:24, ZhangJian He  wrote:

> Thank for StreamNative for willing to donate this project. This means we
> don't have to develop and maintain a set of HTTP code from scratch. My idea
> aligns with Yunze's, and separating it into a standalone pulsar-admin-go
> project would be better. The **pulsarctl** repo contains bookkeeper http
> call too. Maybe we can have a project bookkeeper-admin-go ?（it's a liitle
> going off-topic ）
>
> Thanks
> ZhangJian He
>
>
> On Fri, 17 Feb 2023 at 20:29, PengHui Li  wrote:
>
>> Hi Yunze,
>>
>> Yes, we can split it.
>> Both one repo with two modules or two repos works for me.
>>
>> The pulsarctl already have the admin API and CLI.
>> So I think we don’t need to develop another one.
>>
>> Best,
>> Penghui
>>
>> > On Feb 17, 2023, at 17:44, Yunze Xu 
>> wrote:
>> >
>> > Hi PengHui,
>> >
>> > Now I changed my mind a bit. Even if the pulsarctl was contributed to
>> > the Apache Foundation, I think we should also avoid adding it as the
>> > dependency. What we need is an API layer but not the CLI, while
>> > pulsarctl couples the API and CLI.
>> >
>> > At the moment, my expectation is:
>> > 1. Use a separate repo (e.g. pulsar-admin-go) to implement the admin
>> > APIs in Golang.
>> > 2. Depend this new repo in pulsarctl.
>> >
>> > Then we will have three Go projects:
>> > - pulsar-client-go: The Pulsar Go client APIs
>> > - pulsar-admin-go: The Pulsar Go admin APIs
>> > - pulsarctl: The admin CLI tool written in Go
>> >
>> > Thanks,
>> > Yunze
>> >
>> > On Fri, Feb 17, 2023 at 4:22 PM PengHui Li  wrote:
>> >>
>> >> I checked with Sijie today.
>> >> StreamNative can contribute the pulsarctl project to Apache Foundation.
>> >>
>> >> Regards,
>> >> Penghui
>> >>
>> >> On Fri, Feb 17, 2023 at 4:02 PM Enrico Olivelli 
>> wrote:
>> >>
>> >>> I agree to add an admin API to the go client, this would be very
>> helpful.
>> >>>
>> >>> Il giorno ven 17 feb 2023 alle ore 08:44 Zixuan Liu
>> >>>  ha scritto:
>> 
>>  Hi Zhangjian,
>> 
>>  This is a good idea to write the admin client by golang, but I don't
>>  suggest add the admin features to pulsar-go-client, it's better to
>> use a
>>  new repository to do that to  separate dependencies.
>> 
>>  BTW, StreamNative has a pulsarctl [0] tool, which includes the admin
>> api.
>> 
>> >> It's better to reuse existing code rather than reinventing the
>> wheel.
>> 
>>  I aggred this point. If possible, we can integrate the pulsarctl to
>> this
>>  new project.
>> >>>
>> >>> We are talking about adding a client that calls a
>> >>> well defined and maintained REST API.
>> >>> It is better to have our implementation and not rely on third parties
>> >>> when it is possible.
>> >>> If there is a security issue in pulsarctl, how would we handle that ?
>> >>> Also the Pulsar community maintains the Pulsar API and this is the
>> >>> place where it is easier to keep the client up-to-date with the new
>> >>> APIs that we will develop,
>> >>> we can't wait for a third party project to implement our own APIs and
>> >>> wait for an upgrade (even if it is OSS, we cannot cut releases or have
>> >>> control over the release cycle)
>> >>>
>> >>>
>> >>> Enrico
>> >>>
>> >>>
>> >>>
>> 
>>  [0] - https://github.com/streamnative/pulsarctl
>> 
>>  Thanks,
>>  Zixuan
>> 
>> 
>>  ZhangJian He  于2023年2月17日周五 13:47写道：
>> 
>> > Separating dependencies is better. For example, I think
>> >>> Pulsar-admin-go can
>> > only have golang standard tls and http dependencies.
>> > But it seems impossible to have two go modules when publishing
>> packages
>> > using github.
>> >
>> >> Has anyone tried generating an admin client from our generated open
>> > api spec?
>> >
>> > I have attempted it, but it requires us to modify our Swagger file.
>> Our
>> > existing Swagger file can't generate HTTP clients directly. Perhaps
>> we
>> >>> can
>> > rewrite a unified and standardized Swagger file, and then generate
>> all
>> > code, including brokers, from there gradually.
>> >
>> > Thanks
>> > ZhangJian He
>> >
>> >
>> > On Fri, 17 Feb 2023 at 12:37, Yunze Xu > >
>> > wrote:
>> >
>> >>> I notice that the Java Client and the Java Admin Client are
>> >>> separate
>> >> dependencies. Is this boundary important to maintain for other
>> >> language admin clients?
>> >>
>> >> IMO, separating them is better to maintain. I had an idea to
>> >>> implement
>> >> a pure C implementation of the Pulsar admin API. Only libcurl and
>> >> openssl 

[questions] Which jakartaEE version we plan for pulsar 3.0.0?

[ZhangJian He]

Hello, community. I want to know Which jakartaEE version we plan for pulsar
3.0.0. Now we use jersey 2.x, which uses Jakarta EE8.

Maybe we will need to update the jersey.
Eclipse Jersey (eclipse-ee4j.github.io)

2.x is for Jakarta EE8. 3.0.x is for Jakarta EE9 and 3.1.x is for Jakarta
EE10.

Thank you for your time and consideration.

Thanks
ZhangJian He

Re: [DISCUSSION] Mark Unused/Abandoned Pulsar Git Repositories Read Only

[Michael Marshall]

This is a good initiative.

> (1) GitHub.com/apache/pulsar-client-ruby/ - There is only an initial commit 
> of a README. I think that it should be deleted.

That has two PRs. That makes me think we should move the repo to read
only, instead.

> (2) GitHub.com/apache/pulsar-connectors/ - This was abandoned in Nov 2020. We 
> should make it read only.
> (3) GitHub.com/apache/pulsar-presto/ - This was also abandoned in Nov 2020. 
> We should make it read only.

We need to understand the status of PIP 62 in order to know what to do
for these repos. See
https://lists.apache.org/thread/gj8ctgx91xhysc46pfgdqy7bncymv3vn

Moving the presto integration has been discussed several times before,
but we still have it in the apache/pulsar repo.

Thanks,
Michael

On Fri, Feb 24, 2023 at 3:04 PM Dave Fisher  wrote:
>
> > Hi -
> >
> > We have several unmaintained or abandoned repositories. We should retire 
> > these by either marking them read-only after leaving a README or we should 
> > delete them.
> >
> > (1) GitHub.com/apache/pulsar-client-ruby/ - There is only an initial commit 
> > of a README. I think that it should be deleted.
> >
> > (2) GitHub.com/apache/pulsar-connectors/ - This was abandoned in Nov 2020. 
> > We should make it read only.
> >
> > (3) GitHub.com/apache/pulsar-presto/ - This was also abandoned in Nov 2020. 
> > We should make it read only.
>
> (4) GitHub.com/apache/pulsar-release/ - This was also abandoned in Nov 2020. 
> We should make it read only.
>
> >
> > Best,
> > Dave
>

Re: [DISCUSSION] Mark Unused/Abandoned Pulsar Git Repositories Read Only

[Dave Fisher]

> Hi -
> 
> We have several unmaintained or abandoned repositories. We should retire 
> these by either marking them read-only after leaving a README or we should 
> delete them.
> 
> (1) GitHub.com/apache/pulsar-client-ruby/ - There is only an initial commit 
> of a README. I think that it should be deleted.
> 
> (2) GitHub.com/apache/pulsar-connectors/ - This was abandoned in Nov 2020. We 
> should make it read only.
> 
> (3) GitHub.com/apache/pulsar-presto/ - This was also abandoned in Nov 2020. 
> We should make it read only.

(4) GitHub.com/apache/pulsar-release/ - This was also abandoned in Nov 2020. We 
should make it read only.

> 
> Best,
> Dave

[DISCUSSION] Mark Unused/Abandoned Pulsar Git Repositories Read Only

[Dave Fisher]

Hi -

We have several unmaintained or abandoned repositories. We should retire these 
by either marking them read-only after leaving a README or we should delete 
them.

(1) GitHub.com/apache/pulsar-client-ruby/ - There is only an initial commit of 
a README. I think that it should be deleted.

(2) GitHub.com/apache/pulsar-connectors/ - This was abandoned in Nov 2020. We 
should make it read only.

(3) GitHub.com/apache/pulsar-presto/ - This was also abandoned in Nov 2020. We 
should make it read only.

Best,
Dave

Re: [DISCUSS] Apache Pulsar Adapters 2.11.0 release

[Enrico Olivelli]

+1
thanks

I wonder if there are other sub-projects that we should release
together with 2.10.0

Enrico

Il giorno ven 24 feb 2023 alle ore 17:33 Christophe Bornet
 ha scritto:
>
> Hi everyone,
>
> The last release of the Pulsar Adapters was 2.8.0 in July 2021.
> Even though there is not much activity on this repo, there has been
> some bug fixes since then including one for the famous Log4Shell CVE.
> So I'd like to propose myself as a release manager for a Pulsar
> Adapters 2.11.0 release. I'll also update the dependency on Pulsar to
> use 2.11.
> Please tell if you have things you want to do, issues you want to see
> fixed or PRs you'd like to see merged before this release.
>
> Best regards.
>
> Christophe Bornet

Re: [DISCUSS] PIP-247: Notifications for partitions update

[Michael Marshall]

> Just the way to implements partitioned-topic metadata
> notification mechanism is much like notifications on regex sub changes

Why do we need a separate notification implementation? The regex
subscription feature is about discovering topics (not subscriptions)
that match a regular expression. As Joe mentioned, I think we just
need the client to "subscribe" to a topic notification for
"-partition-[0-9]+" to eliminate the polling.

Building on PIP 145, the work for this PIP would be in implementing a
different `TopicsChangedListener` [1] so that the result of an added
topic is to add a producer/consumer to the new partition.

I support removing polling in our streaming platform, but I'd prefer
to limit the number of notification systems we implement.

Thanks,
Michael

[0] https://github.com/apache/pulsar/pull/16062
[1] 
https://github.com/apache/pulsar/blob/82237d3684fe506bcb6426b3b23f413422e6e4fb/pulsar-client/src/main/java/org/apache/pulsar/client/impl/PatternMultiTopicsConsumerImpl.java#L169-L175



On Fri, Feb 24, 2023 at 1:57 AM houxiaoyu  wrote:
>
> Hi Joe,
>
> When we use PartitionedProducerImpl or MultiTopicsConsumerImpl,  there is a
> poll task to fetch the metadata of the partitioned-topic regularly for the
> number of partitions updated.  This PIP wants to use a
> notification mechanism to replace the metadata poll task.
>
> Just the way to implements partitioned-topic metadata
> notification mechanism is much like notifications on regex sub changes
>
> Joe F  于2023年2月24日周五 13:37写道：
>
> > Why is this needed when we have notifications on regex sub changes? Aren't
> > the partition names a well-defined regex?
> >
> > Joe
> >
> > On Thu, Feb 23, 2023 at 8:52 PM houxiaoyu  wrote:
> >
> > > Hi Asaf,
> > > thanks for your reminder.
> > >
> > > ## Changing
> > > I have updated the following changes to make sure the notification
> > arrived
> > > successfully:
> > > 1. The watch success response `CommandWatchPartitionUpdateSuccess` will
> > > contain all the concerned topics of this watcher
> > > 2. The notification `CommandPartitionUpdate` will always contain all the
> > > concerned topics of this watcher.
> > > 3. The notification `CommandPartitionUpdate`contains a monotonically
> > > increased version.
> > > 4. A map `PartitonUpdateWatcherService#inFlightUpdate > > Pair>` will keep track of the updating
> > > 5. A timer will check the updating timeout through `inFlightUpdate`
> > > 6. The client acks `CommandPartitionUpdateResult` to broker when it
> > > finishes updating.
> > >
> > > ## Details
> > >
> > > The following mechanism could make sure the newest notification arrived
> > > successfully, copying the description from GH:
> > >
> > > A new class, `org.apache.pulsar.PartitonUpdateWatcherService` will keep
> > > track of watchers and will listen to the changes in the metadata.
> > Whenever
> > > a topic partition updates it checks if any watchers should be notified
> > and
> > > sends an update for all topics the watcher concerns through the
> > ServerCnx.
> > > Then we will record this request into a map,
> > > `PartitonUpdateWatcherService#inFlightUpdate > Pair > > long/*timestamp*/>>`.  A timer will check this update timeout through
> > > inFlightUpdate .  We will query all the concerned topics's partition if
> > > this watcher has sent an update timeout and will resend it.
> > >
> > > The client acks `CommandPartitionUpdateResult` to broker when it finishes
> > > updating.  The broker handle `CommandPartitionUpdateResult` request:
> > >  - If CommandPartitionUpdateResult#version <
> > > PartitonUpdateWatcherService#inFlightUpdate.get(watcherID).version,
> > broker
> > > ignores this ack.
> > >  -  If CommandPartitionUpdateResult#version ==
> > > PartitonUpdateWatcherService#inFlightUpdate.get(watcherID).version
> > > - If CommandPartitionUpdateResult#success is true,  broker just
> > removes
> > > the watcherID from inFlightUpdate.
> > > - If CommandPartitionUpdateResult#success is false,  broker removes
> > the
> > > watcherId from inFlightUpdate, and queries all the concerned topics's
> > > partition and resend.
> > >  - If CommandPartitionUpdateResult#version >
> > > PartitonUpdateWatcherService#inFlightUpdate.get(watcherID).version, this
> > > should not happen.
> > >
> > >  ## Edge cases
> > > - Broker restarts or crashes
> > > Client will reconnect to another broker, broker responses
> > > `CommandWatchPartitionUpdateSuccess` with watcher concerned topics's
> > > partitions.  We will call `PartitionsUpdateListener` if the connection
> > > opens.
> > > - Client acks fail or timeout
> > > Broker will resend the watcher concerned topics's partitions either
> > client
> > > acks fail or acks timeout.
> > > - Partition updates before client acks.
> > > `CommandPartitionUpdate#version` monotonically increases every time it is
> > > updated. If Partition updates before client acks, a greater version will
> > be
> > > put into `PartitonUpdateWatcherService#inFlightUpdate`.  The 

Re: [DISCUSS] PIP-250: Add proxyVersion to CommandConnect

[Michael Marshall]

Great suggestions, Enrico.

> It would be interesting to reject connections on the Proxy if the
> client tries to set that field.

I support making the proxy reject invalid input. We could also have
the client reject connections where the client connect command
includes `original_principal`, `original_auth_data`, or
`original_auth_method`, since those are also only meant to be sent by
the proxy.

> On the broker there is no way to distinguish a proxy from a client, that's 
> fair.

We can reject these connections when authentication and authorization
are enabled. My draft PR includes such logic.

Thanks,
Michael

On Fri, Feb 24, 2023 at 7:29 AM Enrico Olivelli  wrote:
>
> Makes sense.
>
> It would be interesting to reject connections on the Proxy if the
> client tries to set that field.
> On the broker there is no way to distinguish a proxy from a client, that's 
> fair.
> But on the proxy it is not expected to see a connection from another proxy.
>
> +1
>
> Enrico
>
> Il giorno ven 24 feb 2023 alle ore 10:00 Zike Yang  ha 
> scritto:
> >
> > Hi, Michael
> >
> > Thanks for initiating this PIP.
> >
> > +1
> >
> > BR,
> > Zike Yang
> >
> >
> > Zike Yang
> >
> > On Fri, Feb 24, 2023 at 12:16 PM Michael Marshall  
> > wrote:
> > >
> > > Hi Pulsar Community,
> > >
> > > In talking with Zike Yang on
> > > https://github.com/apache/pulsar/pull/19540, we identified that it
> > > would be helpful for the proxy to forward its own version when
> > > connecting to the broker. Here is a related PIP to improve the
> > > connection information available to operators.
> > >
> > > Issue: https://github.com/apache/pulsar/issues/19623
> > > Implementation: https://github.com/apache/pulsar/pull/19618
> > >
> > > I look forward to your feedback!
> > >
> > > Thanks,
> > > Michael
> > >
> > > Text of PIP copied below:
> > >
> > > ### Motivation
> > >
> > > When clients connect through the proxy, it is valuable to know which
> > > version of the proxy connected to the broker. That information isn't
> > > currently logged or reported in any easily identifiable way. The only
> > > way to get information about the connection is to infer which proxy
> > > forwarded a connection based on matching up the IP address in the
> > > logs.
> > >
> > > An additional change proposed in the implementation is to log this new
> > > information along with the `clientVersion`, `clientProtocolVersion`,
> > > and relevant authentication role information. This information will
> > > improve debug-ability and could also serve as a form of audit logging.
> > >
> > > ### Goal
> > >
> > > Improve the value of the broker's logs and metrics about connections
> > > to simplify debugging and to make it easier for Pulsar operators to
> > > understand how clients are connecting to their clusters.
> > >
> > > ### API Changes
> > >
> > > Add the following:
> > >
> > > ```proto
> > > message CommandConnect {
> > >  // Other fields omitted
> > > optional string proxy_version = 11; // Version of the proxy.
> > > Should only be forwarded by a proxy.
> > > }
> > > ```
> > >
> > > ### Implementation
> > >
> > > Initial implementation: https://github.com/apache/pulsar/pull/19618
> > >
> > > ### Alternatives
> > >
> > > The `CommandAuthResponse` has a `client_version` field. It's possible
> > > that someone would want this `proxy_version` field on that message.
> > > However, I think we should not continue down the path of duplicating
> > > fields in the connection handshake protocol.
> > >
> > > ### Anything else?
> > >
> > > Future work could include exposing this `proxyVersion` and
> > > `clientVersion` information via Prometheus metrics.

Re: [DISCUSS] PIP-249: Pulsar website redesign

[Asaf Mesika]

You are correct - we did start with what content we wanted to show, then
designed it to fit that content.
We are releasing it for discussion, iteration and approval, piece by piece,
as I said before since it's easier for everyone reviewing it do it in small
pieces (just like in code).

The “Homepage structure” point is defined in the PIP’s scope, so I thought
> it meant content changing is implied at this step.
>

The "homepage structure" is detailed in the PIP and composed of:

   - News banner
   - Testimonials
   - Menu
   - Footer

As you see it does not mean content changing as this, as we leave that to
future steps.



On Fri, Feb 24, 2023 at 4:51 PM Kiryl Valkovich 
wrote:

> Asaf, okay. I see you have some plan.
>
> I’m just a bit confused with the steps ordering.
> Usually, such work starts with “What content do we want to show?” That
> implies content changes.
> Then “How can we display this content in the best way?”. That implies the
> work on visual design and content adjustment.
> Of course, this order is not mandatory, but it usually allows to save time
> on the number of iterations.
> The “Homepage structure” point is defined in the PIP’s scope, so I thought
> it meant content changing is implied at this step.
> Waiting for the finished site. :)
> By the way, does someone have any more opinions on the topic?
>
> From: Asaf Mesika 
> Date: Friday, February 24, 2023 at 3:06 PM
> To: dev@pulsar.apache.org 
> Subject: Re: [DISCUSS] PIP-249: Pulsar website redesign
> I totally agree with your point Kyril, and as I wrote in the welcome email
> - I want to do all you wrote, but it has to be in bite size pieces. This
> piece is about theme and general look and feel. We "force" ourselves, by
> design, to avoid any content change - just like in code in this proposal -
> so people can focus only on the theme change. It's like in code - you take
> an epic, break it down to stories, and each is broken down to small PRs.
>
> So yes, I have a pipeline of content changes:
> * Landing page:
> ** "Tell me about the pulsar community" section - containing exactly what
> you wanted. We gather great statistics that show the growing community in
> nice numbers, which can also feature company names
> ** "Use cases and applications" - so people can know how Pulsar is used by
> companies (small and big)
> and more.
>
> * Documentation:
>As you probably know - the documentation itself is an encyclopedia, so I
> planned next week a PIP presenting a new structure (super high level) and
> presenting in detail the first section I'd like to focus on: Quick-start
> Guide.
>
> Each such change will be open for discussion to make it the best possible
> addition to the site.
>
> I'm happy you liked the look and feel (design) proposed (Emidio is happy
> too).
>
>
> On Fri, Feb 24, 2023 at 10:21 AM Kiryl Valkovich
> 
> wrote:
>
> > While I find the proposed visual changes okay, I'm unsure about the
> > homepage structure.
> >
> > I'd add one obvious point to the Goal section that can be formulated
> > differently, but eventually is:
> > - **The goal is to get more companies to start using Pulsar.**
> >
> > In other words, the landing page should **sell** the project to potential
> > users.
> >
> > The defined scope of this PIP includes the "Homepage structure" point. I
> > will try to express my thoughts on this.
> >
> > ## Add "Trusted by" or "Used in production" section
> >
> > One of the best hooks to attract new customers is to show that their
> peers
> > or more prominent players use it.
> >
> > This is why I think it's essential to show the list of companies that use
> > Pulsar as closer to the page top, as possible.
> >
> > *Kafka in some form has this info on the first screen*
> >  >
> https://user-images.githubusercontent.com/9302460/221116492-b77cb8e9-eca1-46bd-b457-6889f4e708b6.png
> > >
> >
> > *Confluent has it on the second screen*
> >  >
> https://user-images.githubusercontent.com/9302460/221114783-4f22394e-d1fd-4640-8264-3b137f44e2a1.png
> > >
> >
> > *StreamNative has it on the second screen*
> >  >
> https://user-images.githubusercontent.com/9302460/221116665-6749212f-749f-4221-b175-07261a6d2ed5.png
> > >
> >
> > *Redpanda has it on the second screen*
> >  >
> https://user-images.githubusercontent.com/9302460/221118114-aabaee99-f6ef-4586-b7df-02c5ca3b24a6.png
> > >
> >
> > The homepage structure proposed in the PIP doesn't have a list of the
> > companies on the page itself. Instead, it has a testimonials list at the
> > **bottom** of the page with a link to case-studies.
> >
> > ## Too much text on the second screen
> >
> > Users don't like to read long texts on landing pages. They'll just skip
> it.
> > Show the same or similar text in a bullet-point-like style would be
> better.
> >
> >  >
> https://user-images.githubusercontent.com/9302460/221119160-5a39c7c9-ad68-4332-961a-e941f3a76693.png
> > >
> >
> > ## The Pulsar Features section
> >
> > Questions the potential user implicitly asks when they scroll 

[DISCUSS] Apache Pulsar Adapters 2.11.0 release

[Christophe Bornet]

Hi everyone,

The last release of the Pulsar Adapters was 2.8.0 in July 2021.
Even though there is not much activity on this repo, there has been
some bug fixes since then including one for the famous Log4Shell CVE.
So I'd like to propose myself as a release manager for a Pulsar
Adapters 2.11.0 release. I'll also update the dependency on Pulsar to
use 2.11.
Please tell if you have things you want to do, issues you want to see
fixed or PRs you'd like to see merged before this release.

Best regards.

Christophe Bornet

Re: [DISCUSS] PIP-249: Pulsar website redesign

[Asaf Mesika]

On Fri, Feb 24, 2023 at 5:31 PM Dave Fisher  wrote:

> Hi -
>
> While I like this design effort so far -
>
> 1. The design needs to show how the site looks on smaller @media like
> iPhones.
>

The PIP is mainly about the design concepts as displayed in the PIP, before
proceeding with the heavy lifting of implementing it. No point in investing
huge efforts before the general design is voted upon.
Once approved, and work will start, we will start working on it in PRs,
which will be a workable site. I believe at those stages we will show how
it will look on iPhones and the like. I believe the important bit in this
PIP is to make sure people are ok with the look and feel of the suggested
theme.


>
> 2. The horizontal carousel at the bottom looks a little awkward. Will it
> automatically shift?
>

This is something we can leave to the PR stages, so we can try both options
and see what works best, while each person reviewing it can "play" with it
live on their laptop or staging site.


>
> 3. The website design was refreshed in 2021-2022. It was a difficult and
> lengthy process. It is ok that you do not think it is modern and could be
> better. Please do not disparage the efforts of previous volunteers to
> justify your efforts.
>
>
Sorry it came out this way Dave, this wasn't the intention. As you've seen
in the bi-weekly meetings, I'm rather new here, and my intentions are
mainly to make Pulsar better and the community bigger so everybody can
enjoy Pulsar as I do.

I'm happy you liked the design!

Cheers,

Asaf


> Best,
> Dave
>
> Sent from my iPhone
>
> > On Feb 23, 2023, at 1:27 PM, Asaf Mesika  wrote:
> >
> > Hi,
> >
> > PIP issue: https://github.com/apache/pulsar/issues/19611
> >
> > One of the key elements that attracted me to Pulsar was how awesome it
> is -
> > built in 2012 yet fits the new strategy of being cloud-native - simply
> > incredible. It's not only that - it has so many outstanding features,
> > making it a cutting edge, modern powerhouse in the messaging system
> > category.
> >
> > Yet, its site does not reflect that.
> > It does the opposite.
> > People new to Pulsar, not knowing it as we do in the community, would
> think
> > it's an old, unmaintained technology, and maybe not even bother reading
> the
> > landing page.
> >
> > This is why I embarked on a journey to improve Pulsar web-site, in bite
> > sizes. My first step was improving the landing page copy for the elevator
> > pitch, opening paragraph, and the feature descriptions (In this PR
> > )
> >
> > Today, together with my friend, co-worker and designer Emidio, I would
> like
> > to propose the second step: revamp the landing page structure and most
> > importantly - the website look and feel.
> >
> > The PIP  contains:
> > * The screenshots for it
> > * A "live" Figma view for it
> > * Detailed explanation of what was changed and why.
> >
> > I think you'll love it.
> >
> > Happy to hear your thoughts.
> >
> >
> > Asaf Mesika
>
>

Re: [DISCUSS] PIP-249: Pulsar website redesign

[Dave Fisher]

Hi -

While I like this design effort so far -

1. The design needs to show how the site looks on smaller @media like iPhones.

2. The horizontal carousel at the bottom looks a little awkward. Will it 
automatically shift?

3. The website design was refreshed in 2021-2022. It was a difficult and 
lengthy process. It is ok that you do not think it is modern and could be 
better. Please do not disparage the efforts of previous volunteers to justify 
your efforts.

Best,
Dave

Sent from my iPhone

> On Feb 23, 2023, at 1:27 PM, Asaf Mesika  wrote:
> 
> Hi,
> 
> PIP issue: https://github.com/apache/pulsar/issues/19611
> 
> One of the key elements that attracted me to Pulsar was how awesome it is -
> built in 2012 yet fits the new strategy of being cloud-native - simply
> incredible. It's not only that - it has so many outstanding features,
> making it a cutting edge, modern powerhouse in the messaging system
> category.
> 
> Yet, its site does not reflect that.
> It does the opposite.
> People new to Pulsar, not knowing it as we do in the community, would think
> it's an old, unmaintained technology, and maybe not even bother reading the
> landing page.
> 
> This is why I embarked on a journey to improve Pulsar web-site, in bite
> sizes. My first step was improving the landing page copy for the elevator
> pitch, opening paragraph, and the feature descriptions (In this PR
> )
> 
> Today, together with my friend, co-worker and designer Emidio, I would like
> to propose the second step: revamp the landing page structure and most
> importantly - the website look and feel.
> 
> The PIP  contains:
> * The screenshots for it
> * A "live" Figma view for it
> * Detailed explanation of what was changed and why.
> 
> I think you'll love it.
> 
> Happy to hear your thoughts.
> 
> 
> Asaf Mesika

Re: [DISCUSS] PIP-249: Pulsar website redesign

[Kiryl Valkovich]

Asaf, okay. I see you have some plan.

I’m just a bit confused with the steps ordering.
Usually, such work starts with “What content do we want to show?” That implies 
content changes.
Then “How can we display this content in the best way?”. That implies the work 
on visual design and content adjustment.
Of course, this order is not mandatory, but it usually allows to save time on 
the number of iterations.
The “Homepage structure” point is defined in the PIP’s scope, so I thought it 
meant content changing is implied at this step.
Waiting for the finished site. :)
By the way, does someone have any more opinions on the topic?

From: Asaf Mesika 
Date: Friday, February 24, 2023 at 3:06 PM
To: dev@pulsar.apache.org 
Subject: Re: [DISCUSS] PIP-249: Pulsar website redesign
I totally agree with your point Kyril, and as I wrote in the welcome email
- I want to do all you wrote, but it has to be in bite size pieces. This
piece is about theme and general look and feel. We "force" ourselves, by
design, to avoid any content change - just like in code in this proposal -
so people can focus only on the theme change. It's like in code - you take
an epic, break it down to stories, and each is broken down to small PRs.

So yes, I have a pipeline of content changes:
* Landing page:
** "Tell me about the pulsar community" section - containing exactly what
you wanted. We gather great statistics that show the growing community in
nice numbers, which can also feature company names
** "Use cases and applications" - so people can know how Pulsar is used by
companies (small and big)
and more.

* Documentation:
   As you probably know - the documentation itself is an encyclopedia, so I
planned next week a PIP presenting a new structure (super high level) and
presenting in detail the first section I'd like to focus on: Quick-start
Guide.

Each such change will be open for discussion to make it the best possible
addition to the site.

I'm happy you liked the look and feel (design) proposed (Emidio is happy
too).


On Fri, Feb 24, 2023 at 10:21 AM Kiryl Valkovich 
wrote:

> While I find the proposed visual changes okay, I'm unsure about the
> homepage structure.
>
> I'd add one obvious point to the Goal section that can be formulated
> differently, but eventually is:
> - **The goal is to get more companies to start using Pulsar.**
>
> In other words, the landing page should **sell** the project to potential
> users.
>
> The defined scope of this PIP includes the "Homepage structure" point. I
> will try to express my thoughts on this.
>
> ## Add "Trusted by" or "Used in production" section
>
> One of the best hooks to attract new customers is to show that their peers
> or more prominent players use it.
>
> This is why I think it's essential to show the list of companies that use
> Pulsar as closer to the page top, as possible.
>
> *Kafka in some form has this info on the first screen*
>  https://user-images.githubusercontent.com/9302460/221116492-b77cb8e9-eca1-46bd-b457-6889f4e708b6.png
> >
>
> *Confluent has it on the second screen*
>  https://user-images.githubusercontent.com/9302460/221114783-4f22394e-d1fd-4640-8264-3b137f44e2a1.png
> >
>
> *StreamNative has it on the second screen*
>  https://user-images.githubusercontent.com/9302460/221116665-6749212f-749f-4221-b175-07261a6d2ed5.png
> >
>
> *Redpanda has it on the second screen*
>  https://user-images.githubusercontent.com/9302460/221118114-aabaee99-f6ef-4586-b7df-02c5ca3b24a6.png
> >
>
> The homepage structure proposed in the PIP doesn't have a list of the
> companies on the page itself. Instead, it has a testimonials list at the
> **bottom** of the page with a link to case-studies.
>
> ## Too much text on the second screen
>
> Users don't like to read long texts on landing pages. They'll just skip it.
> Show the same or similar text in a bullet-point-like style would be better.
>
>  https://user-images.githubusercontent.com/9302460/221119160-5a39c7c9-ad68-4332-961a-e941f3a76693.png
> >
>
> ## The Pulsar Features section
>
> Questions the potential user implicitly asks when they scroll the landing
> page sound like:
>
> > 樂 How can this project help me to solve my pain points?
> > 樂 Why should I "buy" this?
>
> The answers to this question aren't limited to the technical features list.
>
> The current PIP doesn't seem to answer these questions.
>
> ---
>
> ## Alternative page structure proposal
>
> 陋 Here it is: https://pulsar-site-three.vercel.app/
>
> I would be happy to work with the designer if most users prefer the PIP's
> visual style.
>
> My goal is not to compete here "just for fun". My company works on a
> product for Pulsar users, so I'm in some kind of dependent on a wider
> Pulsar adoption.
>
> Thank you.
>
>
> From: Yu 
> Date: Friday, February 24, 2023 at 3:55 AM
> To: dev@pulsar.apache.org 
> Subject: Re: [DISCUSS] PIP-249: Pulsar website redesign
> Hi @asafm and @emidio-cardeira thanks for your great work!
>
> You've contributed new designs (with 

Re: [DISCUSS] PIP-249: Pulsar website redesign

[Asaf Mesika]

I totally agree with your point Kyril, and as I wrote in the welcome email
- I want to do all you wrote, but it has to be in bite size pieces. This
piece is about theme and general look and feel. We "force" ourselves, by
design, to avoid any content change - just like in code in this proposal -
so people can focus only on the theme change. It's like in code - you take
an epic, break it down to stories, and each is broken down to small PRs.

So yes, I have a pipeline of content changes:
* Landing page:
** "Tell me about the pulsar community" section - containing exactly what
you wanted. We gather great statistics that show the growing community in
nice numbers, which can also feature company names
** "Use cases and applications" - so people can know how Pulsar is used by
companies (small and big)
and more.

* Documentation:
   As you probably know - the documentation itself is an encyclopedia, so I
planned next week a PIP presenting a new structure (super high level) and
presenting in detail the first section I'd like to focus on: Quick-start
Guide.

Each such change will be open for discussion to make it the best possible
addition to the site.

I'm happy you liked the look and feel (design) proposed (Emidio is happy
too).


On Fri, Feb 24, 2023 at 10:21 AM Kiryl Valkovich 
wrote:

> While I find the proposed visual changes okay, I'm unsure about the
> homepage structure.
>
> I'd add one obvious point to the Goal section that can be formulated
> differently, but eventually is:
> - **The goal is to get more companies to start using Pulsar.**
>
> In other words, the landing page should **sell** the project to potential
> users.
>
> The defined scope of this PIP includes the "Homepage structure" point. I
> will try to express my thoughts on this.
>
> ## Add "Trusted by" or "Used in production" section
>
> One of the best hooks to attract new customers is to show that their peers
> or more prominent players use it.
>
> This is why I think it's essential to show the list of companies that use
> Pulsar as closer to the page top, as possible.
>
> *Kafka in some form has this info on the first screen*
>  https://user-images.githubusercontent.com/9302460/221116492-b77cb8e9-eca1-46bd-b457-6889f4e708b6.png
> >
>
> *Confluent has it on the second screen*
>  https://user-images.githubusercontent.com/9302460/221114783-4f22394e-d1fd-4640-8264-3b137f44e2a1.png
> >
>
> *StreamNative has it on the second screen*
>  https://user-images.githubusercontent.com/9302460/221116665-6749212f-749f-4221-b175-07261a6d2ed5.png
> >
>
> *Redpanda has it on the second screen*
>  https://user-images.githubusercontent.com/9302460/221118114-aabaee99-f6ef-4586-b7df-02c5ca3b24a6.png
> >
>
> The homepage structure proposed in the PIP doesn't have a list of the
> companies on the page itself. Instead, it has a testimonials list at the
> **bottom** of the page with a link to case-studies.
>
> ## Too much text on the second screen
>
> Users don't like to read long texts on landing pages. They'll just skip it.
> Show the same or similar text in a bullet-point-like style would be better.
>
>  https://user-images.githubusercontent.com/9302460/221119160-5a39c7c9-ad68-4332-961a-e941f3a76693.png
> >
>
> ## The Pulsar Features section
>
> Questions the potential user implicitly asks when they scroll the landing
> page sound like:
>
> > 樂 How can this project help me to solve my pain points?
> > 樂 Why should I "buy" this?
>
> The answers to this question aren't limited to the technical features list.
>
> The current PIP doesn't seem to answer these questions.
>
> ---
>
> ## Alternative page structure proposal
>
> 陋 Here it is: https://pulsar-site-three.vercel.app/
>
> I would be happy to work with the designer if most users prefer the PIP's
> visual style.
>
> My goal is not to compete here "just for fun". My company works on a
> product for Pulsar users, so I'm in some kind of dependent on a wider
> Pulsar adoption.
>
> Thank you.
>
>
> From: Yu 
> Date: Friday, February 24, 2023 at 3:55 AM
> To: dev@pulsar.apache.org 
> Subject: Re: [DISCUSS] PIP-249: Pulsar website redesign
> Hi @asafm and @emidio-cardeira thanks for your great work!
>
> You've contributed new designs (with colors/elements/... that have not been
> used) for Pulsar, which is a big step for the community.
>
> Preiviously we've collected some rules at Pulsar Design Style Guide [1],
> which are used to create illustrations in docs.
>
> If this new look is accepted, can you document the design rules/best
> practice? They should be available in the Contribution Guide [2].
>
> In this way, other contributors can follow and create designs in high
> quality and consistent style.
>
> Thanks!
>
> ~
>
> [1]
>
> https://docs.google.com/document/d/16Hp7Sc86MQtL0m8fc2w_TrcKXAuglwRwHmdmwfk00mI/edit#heading=h.b8ogodj5sj
>
> [2] https://pulsar.apache.org/contribute/
>
>
> On Fri, Feb 24, 2023 at 5:27 AM Asaf Mesika  wrote:
>
> > Hi,
> >
> > PIP issue: https://github.com/apache/pulsar/issues/19611
> >

Re: [DISCUSS] PIP-250: Add proxyVersion to CommandConnect

[Enrico Olivelli]

Makes sense.

It would be interesting to reject connections on the Proxy if the
client tries to set that field.
On the broker there is no way to distinguish a proxy from a client, that's fair.
But on the proxy it is not expected to see a connection from another proxy.

+1

Enrico

Il giorno ven 24 feb 2023 alle ore 10:00 Zike Yang  ha scritto:
>
> Hi, Michael
>
> Thanks for initiating this PIP.
>
> +1
>
> BR,
> Zike Yang
>
>
> Zike Yang
>
> On Fri, Feb 24, 2023 at 12:16 PM Michael Marshall  
> wrote:
> >
> > Hi Pulsar Community,
> >
> > In talking with Zike Yang on
> > https://github.com/apache/pulsar/pull/19540, we identified that it
> > would be helpful for the proxy to forward its own version when
> > connecting to the broker. Here is a related PIP to improve the
> > connection information available to operators.
> >
> > Issue: https://github.com/apache/pulsar/issues/19623
> > Implementation: https://github.com/apache/pulsar/pull/19618
> >
> > I look forward to your feedback!
> >
> > Thanks,
> > Michael
> >
> > Text of PIP copied below:
> >
> > ### Motivation
> >
> > When clients connect through the proxy, it is valuable to know which
> > version of the proxy connected to the broker. That information isn't
> > currently logged or reported in any easily identifiable way. The only
> > way to get information about the connection is to infer which proxy
> > forwarded a connection based on matching up the IP address in the
> > logs.
> >
> > An additional change proposed in the implementation is to log this new
> > information along with the `clientVersion`, `clientProtocolVersion`,
> > and relevant authentication role information. This information will
> > improve debug-ability and could also serve as a form of audit logging.
> >
> > ### Goal
> >
> > Improve the value of the broker's logs and metrics about connections
> > to simplify debugging and to make it easier for Pulsar operators to
> > understand how clients are connecting to their clusters.
> >
> > ### API Changes
> >
> > Add the following:
> >
> > ```proto
> > message CommandConnect {
> >  // Other fields omitted
> > optional string proxy_version = 11; // Version of the proxy.
> > Should only be forwarded by a proxy.
> > }
> > ```
> >
> > ### Implementation
> >
> > Initial implementation: https://github.com/apache/pulsar/pull/19618
> >
> > ### Alternatives
> >
> > The `CommandAuthResponse` has a `client_version` field. It's possible
> > that someone would want this `proxy_version` field on that message.
> > However, I think we should not continue down the path of duplicating
> > fields in the connection handshake protocol.
> >
> > ### Anything else?
> >
> > Future work could include exposing this `proxyVersion` and
> > `clientVersion` information via Prometheus metrics.

Re: [DISCUSS] PIP-250: Add proxyVersion to CommandConnect

[Zike Yang]

Hi, Michael

Thanks for initiating this PIP.

+1

BR,
Zike Yang


Zike Yang

On Fri, Feb 24, 2023 at 12:16 PM Michael Marshall  wrote:
>
> Hi Pulsar Community,
>
> In talking with Zike Yang on
> https://github.com/apache/pulsar/pull/19540, we identified that it
> would be helpful for the proxy to forward its own version when
> connecting to the broker. Here is a related PIP to improve the
> connection information available to operators.
>
> Issue: https://github.com/apache/pulsar/issues/19623
> Implementation: https://github.com/apache/pulsar/pull/19618
>
> I look forward to your feedback!
>
> Thanks,
> Michael
>
> Text of PIP copied below:
>
> ### Motivation
>
> When clients connect through the proxy, it is valuable to know which
> version of the proxy connected to the broker. That information isn't
> currently logged or reported in any easily identifiable way. The only
> way to get information about the connection is to infer which proxy
> forwarded a connection based on matching up the IP address in the
> logs.
>
> An additional change proposed in the implementation is to log this new
> information along with the `clientVersion`, `clientProtocolVersion`,
> and relevant authentication role information. This information will
> improve debug-ability and could also serve as a form of audit logging.
>
> ### Goal
>
> Improve the value of the broker's logs and metrics about connections
> to simplify debugging and to make it easier for Pulsar operators to
> understand how clients are connecting to their clusters.
>
> ### API Changes
>
> Add the following:
>
> ```proto
> message CommandConnect {
>  // Other fields omitted
> optional string proxy_version = 11; // Version of the proxy.
> Should only be forwarded by a proxy.
> }
> ```
>
> ### Implementation
>
> Initial implementation: https://github.com/apache/pulsar/pull/19618
>
> ### Alternatives
>
> The `CommandAuthResponse` has a `client_version` field. It's possible
> that someone would want this `proxy_version` field on that message.
> However, I think we should not continue down the path of duplicating
> fields in the connection handshake protocol.
>
> ### Anything else?
>
> Future work could include exposing this `proxyVersion` and
> `clientVersion` information via Prometheus metrics.

Re: [DISCUSS] PIP-249: Pulsar website redesign

[Kiryl Valkovich]

While I find the proposed visual changes okay, I'm unsure about the homepage 
structure.

I'd add one obvious point to the Goal section that can be formulated 
differently, but eventually is:
- **The goal is to get more companies to start using Pulsar.**

In other words, the landing page should **sell** the project to potential users.

The defined scope of this PIP includes the "Homepage structure" point. I will 
try to express my thoughts on this.

## Add "Trusted by" or "Used in production" section

One of the best hooks to attract new customers is to show that their peers or 
more prominent players use it.

This is why I think it's essential to show the list of companies that use 
Pulsar as closer to the page top, as possible.

*Kafka in some form has this info on the first screen*
https://user-images.githubusercontent.com/9302460/221116492-b77cb8e9-eca1-46bd-b457-6889f4e708b6.png>

*Confluent has it on the second screen*
https://user-images.githubusercontent.com/9302460/221114783-4f22394e-d1fd-4640-8264-3b137f44e2a1.png>

*StreamNative has it on the second screen*
https://user-images.githubusercontent.com/9302460/221116665-6749212f-749f-4221-b175-07261a6d2ed5.png>

*Redpanda has it on the second screen*
https://user-images.githubusercontent.com/9302460/221118114-aabaee99-f6ef-4586-b7df-02c5ca3b24a6.png>

The homepage structure proposed in the PIP doesn't have a list of the companies 
on the page itself. Instead, it has a testimonials list at the **bottom** of 
the page with a link to case-studies.

## Too much text on the second screen

Users don't like to read long texts on landing pages. They'll just skip it.
Show the same or similar text in a bullet-point-like style would be better.

https://user-images.githubusercontent.com/9302460/221119160-5a39c7c9-ad68-4332-961a-e941f3a76693.png>

## The Pulsar Features section

Questions the potential user implicitly asks when they scroll the landing page 
sound like:

> 樂 How can this project help me to solve my pain points?
> 樂 Why should I "buy" this?

The answers to this question aren't limited to the technical features list.

The current PIP doesn't seem to answer these questions.

---

## Alternative page structure proposal

陋 Here it is: https://pulsar-site-three.vercel.app/

I would be happy to work with the designer if most users prefer the PIP's 
visual style.

My goal is not to compete here "just for fun". My company works on a product 
for Pulsar users, so I'm in some kind of dependent on a wider Pulsar adoption.

Thank you.


From: Yu 
Date: Friday, February 24, 2023 at 3:55 AM
To: dev@pulsar.apache.org 
Subject: Re: [DISCUSS] PIP-249: Pulsar website redesign
Hi @asafm and @emidio-cardeira thanks for your great work!

You've contributed new designs (with colors/elements/... that have not been
used) for Pulsar, which is a big step for the community.

Preiviously we've collected some rules at Pulsar Design Style Guide [1],
which are used to create illustrations in docs.

If this new look is accepted, can you document the design rules/best
practice? They should be available in the Contribution Guide [2].

In this way, other contributors can follow and create designs in high
quality and consistent style.

Thanks!

~

[1]
https://docs.google.com/document/d/16Hp7Sc86MQtL0m8fc2w_TrcKXAuglwRwHmdmwfk00mI/edit#heading=h.b8ogodj5sj

[2] https://pulsar.apache.org/contribute/


On Fri, Feb 24, 2023 at 5:27 AM Asaf Mesika  wrote:

> Hi,
>
> PIP issue: https://github.com/apache/pulsar/issues/19611
>
> One of the key elements that attracted me to Pulsar was how awesome it is -
> built in 2012 yet fits the new strategy of being cloud-native - simply
> incredible. It's not only that - it has so many outstanding features,
> making it a cutting edge, modern powerhouse in the messaging system
> category.
>
> Yet, its site does not reflect that.
> It does the opposite.
> People new to Pulsar, not knowing it as we do in the community, would think
> it's an old, unmaintained technology, and maybe not even bother reading the
> landing page.
>
> This is why I embarked on a journey to improve Pulsar web-site, in bite
> sizes. My first step was improving the landing page copy for the elevator
> pitch, opening paragraph, and the feature descriptions (In this PR
> )
>
> Today, together with my friend, co-worker and designer Emidio, I would like
> to propose the second step: revamp the landing page structure and most
> importantly - the website look and feel.
>
> The PIP  contains:
> * The screenshots for it
> * A "live" Figma view for it
> * Detailed explanation of what was changed and why.
>
> I think you'll love it.
>
> Happy to hear your thoughts.
>
>
> Asaf Mesika
>