incubator-wave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Evan Hughes <ehu...@gmail.com>
Subject Re: A Wavy Future
Date Wed, 16 Mar 2016 01:29:00 GMT
Sorry many mistakes, currently on mobile. Meant to say "the OS editors arnt
bad but....."
On 16/03/2016 11:18 AM, "Evan Hughes" <ehugh1@gmail.com> wrote:

> I had a look at quill and react seperatly dismorning, interestingly the
> atom editor is built using react and they have done at least one if not
> more about how they get more performance out of it, moving rendering to the
> gpu and such.
>
> Do you think itll actually be possible to remove ot somewhat from the
> client,  how do we efficently send data to the client that the document has
> changed.
>
> Also we must be very careful abiut what editor we choose if we arnt
> building one inhouse, debugging could destroy us all.
>
> But the c-rendering we could do inhouse then we would have a basis for
> creating a c-editor from scatch. Not that the OS projects are bad but its a
> pretty broad featire set we need.
> On 16/03/2016 11:00 AM, "Joseph Gentle" <me@josephg.com> wrote:
>
>> Sorry, just poking in here -
>>
>> A couple of years ago I worked with QuillJS's author to add OT to
>> quill. Its a rich text editor, which emits user events and Jason (the
>> author) has a module which interprets those events, builds operations
>> and can do OT with them. It doesn't support rich embedding of
>> components yet, but he's working on that now.
>>
>> React's Draft-js might also work well.
>>
>> -J
>>
>> On Wed, Mar 16, 2016 at 11:18 AM, Michael MacFadden
>> <michael.macfadden@gmail.com> wrote:
>> > All,
>> >
>> > A few things on the editor.  For one.  I think ACE is a plain text
>> editor, which I have used for a bunch of things.  Has a great API for
>> collaboration integration, but it is not rich text, which is what wave is
>> all about.  So I don’t think that will work.
>> >
>> > Also, I think perhaps I should clarify the term editor.  I probably
>> used in inappropriately.
>> >
>> > There are two parts to be concerned with.  The first is collaborative
>> rendering.  If you are just looking at a blip, you can still see it change
>> in real time.  So this would be collaborative rendering.  Then when you are
>> actively editing a blip, you need a collaborative editor.  Both are
>> important.
>> >
>> > The main performance issue comes in two places.  First I may have a
>> conversation model that contains hundreds of blips.  Some sort of lazy
>> loading strategy here is probably required and smart attaching and
>> detaching of listeners.  If you have hundreds of blips all rendered at once
>> and all having to have listeners attached to them because any one of them
>> can change at any time you can run into rendering performance issues.
>> Secondarily, if you do have lots of people editing lots of blips, much of
>> that will not be “on screen” for a given user, and you don’t want to be
>> processing all of those events and messing with the DOM if you don’t need
>> to.  So there are performance and complexity issues there.
>> >
>> > Then there is the actual editor.  Building a Rich Text Editor is not
>> trivial (still.. How can this be???).  So you have to deal with all the
>> issues of building a rich text editor.  Then on top of that you want to
>> integrate remote cursors, selections, authorship, etc. into that editor.
>> Most editors do not have that (a few do, and some are easier than others to
>> add that).  So there is complexity here as well.
>> >
>> > If you want to use an open source editor you need one that does the
>> kind of rich text editing you want to do. It needs to either have the
>> collaboration capabilities (shared cursors, etc.) that you want, or it has
>> to be reasonably easy to implement them yourself.  And it needs to have a
>> good enough eventing API for you to hook into it to capture local changes,
>> and to have API to allow you to drive remote changes into it.
>> >
>> > The point being that, the conversation renderer and rich text editor is
>> a very non-trivial component, if the assumption is to roughly replicate
>> what is there.
>> >
>> >
>> > One point I definitely agree with is that the editor itself really
>> should know nothing about OT.  It should be decoupled and just needs to
>> have a good API with good events.
>> >
>> > ~Michael
>> >
>> >
>> >
>> >
>> > On 3/15/16, 10:11 AM, "Pablo Ojanguren" <pablojan@gmail.com> wrote:
>> >
>> >>Talking about editors I suggest ace from mozilla,
>> >>https://en.wikipedia.org/wiki/Ace_%28editor%29
>> >>
>> >>BTW, as example, this is an app we are developing on with SwellRT as
>> >>backend:  http://staging.teem.works , -it is the staging version, you
>> can
>> >>play! ;)-
>> >>
>> >>2016-03-15 17:12 GMT+01:00 Yuri Z <vega113@gmail.com>:
>> >>
>> >>> No, not really. Javascript on client side is enough - this is how it
>> was
>> >>> originally implemented in microwave by antimatter.
>> >>>
>> >>> On Tue, Mar 15, 2016 at 6:08 PM Thomas Wrobel <darkflame@gmail.com>
>> wrote:
>> >>>
>> >>> > Ah, right. I am all for realtime, merely that I was also happy
to
>> lose
>> >>> > it if it meant significantly more simple implementation.
>> >>> >
>> >>> > >>"Otherwise we can use Robot
>> >>> > >>API - like in https://github.com/vega113/microbox"
>> >>> >
>> >>> > Not keen on RobotAPI as every time I read its use it seems to need
>> an
>> >>> > extra server in the chain/
>> >>> > ie;
>> >>> >  ...<>WaveServer <> Google App Engine <> client
>> >>> >
>> >>> > It should be possible with the web today to avoid that and have
>> >>> > clients connect directly to the wave server no? (hopefully using
the
>> >>> > same protocol as any desktop/mobile client).
>> >>> > Of course, I assume you could run host both servers on the same
>> >>> > hardware, but still seems unnecessary to have that extra step.
>> >>> >
>> >>> >
>> >>> > --
>> >>> > http://lostagain.nl <-- our company site.
>> >>> > http://fanficmaker.com <-- our, really,really, bad story generator.
>> >>> >
>> >>> >
>> >>> > On 15 March 2016 at 16:48, Yuri Z <vega113@gmail.com> wrote:
>> >>> > > Yeah, the intention is to have realtime editing. Otherwise
we can
>> use
>> >>> > Robot
>> >>> > > API - like in https://github.com/vega113/microbox
>> >>> > >
>> >>> > > On Tue, Mar 15, 2016 at 5:45 PM Thomas Wrobel <
>> darkflame@gmail.com>
>> >>> > wrote:
>> >>> > >
>> >>> > >> Does it need to be OT aware on that scale? I thought that
was
>> only
>> >>> > >> needed to have fully realtime blip updating rather then
a "edit +
>> >>> > >> submit" system. (whereupon the differences could be calculated
>> >>> > >> separately from the editing)
>> >>> > >> Is the intention then to still have realtime editing ?
or is this
>> >>> > >> needed anyway regardless?
>> >>> > >>
>> >>> > >> I admit I only know the basics of OT and am vaguely remembering
a
>> >>> > >> conversation about realtime blip editing adding complexity
to
>> things.
>> >>> > >>
>> >>> > >> --
>> >>> > >> http://lostagain.nl <-- our company site.
>> >>> > >> http://fanficmaker.com <-- our, really,really, bad
story
>> generator.
>> >>> > >>
>> >>> > >>
>> >>> > >> On 15 March 2016 at 16:30, Yuri Z <vega113@gmail.com>
wrote:
>> >>> > >> > Not really. You would need to make it OT aware. and
then make
>> it
>> >>> > >> efficient.
>> >>> > >> > Lot's of effort.
>> >>> > >> >
>> >>> > >> > On Tue, Mar 15, 2016 at 5:24 PM Thomas Wrobel <
>> darkflame@gmail.com>
>> >>> > >> wrote:
>> >>> > >> >
>> >>> > >> >> As a side, I noticed Michael MacFadden mentioned
building a
>> rich
>> >>> text
>> >>> > >> >> editor in the browser, this much at least have
been done in
>> GWT
>> >>> > >> >> libraries;
>> >>> > >> >>
>> >>> > >> >>
>> >>> > >>
>> >>> >
>> >>>
>> http://www.gwtproject.org/javadoc/latest/com/google/gwt/user/client/ui/RichTextArea.html
>> >>> > >> >>
>> >>> > >> >> Its fairly basic, but then, I would assume to
start with at
>> least
>> >>> any
>> >>> > >> >> new wave client should stay fairly basic?
>> >>> > >> >> --
>> >>> > >> >> http://lostagain.nl <-- our company site.
>> >>> > >> >> http://fanficmaker.com <-- our, really,really,
bad story
>> >>> generator.
>> >>> > >> >>
>> >>> > >> >>
>> >>> > >> >> On 15 March 2016 at 15:48, Yuri Z <vega113@gmail.com>
wrote:
>> >>> > >> >> > Yeah, we need to re-use the existing editor.
Patches would
>> be
>> >>> > great!
>> >>> > >> >> >
>> >>> > >> >> > On Tue, Mar 15, 2016 at 4:46 PM Pablo Ojanguren
<
>> >>> > pablojan@gmail.com>
>> >>> > >> >> wrote:
>> >>> > >> >> >
>> >>> > >> >> >> Hi,
>> >>> > >> >> >>
>> >>> > >> >> >> I agree with the dependency hell issue
and the suggestion
>> for
>> >>> > >> throwing
>> >>> > >> >> >> away the GWT client. This would require
a new
>> client-server API
>> >>> as
>> >>> > >> >> >> suggested, however I think a Rest API
won't be enough,
>> because
>> >>> > real
>> >>> > >> >> editing
>> >>> > >> >> >> needs websocket.
>> >>> > >> >> >>
>> >>> > >> >> >> I also agree with Michael, developing
a new editor is a
>> massive
>> >>> > >> task, so
>> >>> > >> >> >> we should use an existing one and plug
it in the new API.
>> >>> > >> >> >>
>> >>> > >> >> >> To write again the server in other language
would be
>> great, but
>> >>> I
>> >>> > >> think
>> >>> > >> >> it
>> >>> > >> >> >> requires a huge effort.
>> >>> > >> >> >>
>> >>> > >> >> >> I will be happy to help in decoupling
the server-client, I
>> can
>> >>> > >> provide
>> >>> > >> >> the
>> >>> > >> >> >> experience from my fork. And I plan
to send some patches
>> to Wave
>> >>> > >> soon.
>> >>> > >> >> >>
>> >>> > >> >> >>
>> >>> > >> >> >> These are some slides about my fork
(swellrt) it could
>> give you
>> >>> > some
>> >>> > >> >> ideas:
>> >>> > >> >> >>
>> >>> > >> >> >>
>> >>> > >> >>
>> >>> > >>
>> >>> >
>> >>>
>> https://docs.google.com/presentation/d/1WFDS_m7eyNjBjcdPs0zH496Y9bMSl0_JnSEYGjxNFn0/edit?usp=sharing
>> >>> > >> >> >>
>> >>> > >> >> >>
>> >>> > >> >>
>> >>> > >>
>> >>> >
>> >>>
>> https://docs.google.com/presentation/d/18hMYyECo5EmQsrAb8DT6SkO7LksWVJnhdZmqeCsar4c/edit?usp=sharing
>> >>> > >> >> >>
>> >>> > >> >> >> btw, I would like to start a business
providing these
>> SwellRT
>> >>> > >> services.
>> >>> > >> >> >>
>> >>> > >> >> >>
>> >>> > >> >> >>
>> >>> > >> >> >> 2016-03-14 23:27 GMT+01:00 Joseph Gentle
<me@josephg.com>:
>> >>> > >> >> >>
>> >>> > >> >> >>> I've been playing with the idea
of starting a company
>> around a
>> >>> > >> rewrite
>> >>> > >> >> of
>> >>> > >> >> >>> wave for years.
>> >>> > >> >> >>>
>> >>> > >> >> >>> -J
>> >>> > >> >> >>>
>> >>> > >> >> >>> On Tuesday, 15 March 2016, Adam
Bielski
>> >>> > <a_bielski@ymail.com.invalid
>> >>> > >> >
>> >>> > >> >> >>> wrote:
>> >>> > >> >> >>>
>> >>> > >> >> >>> > Hiya all!I wish I could find
out who is potentially
>> >>> interested
>> >>> > in
>> >>> > >> >> >>> creating
>> >>> > >> >> >>> > the WAVE for a commercial service/productwith
my seed
>> >>> > >> startup!Cheers!
>> >>> > >> >> >>> > Adam
>> >>> > >> >> >>> >
>> >>> > >> >> >>> >     20:23 poniedziałek, 2016-3-14,
Zachary Yaro <
>> >>> > zmyaro@gmail.com
>> >>> > >> >> >>> > <javascript:;>> napisał(a):
>> >>> > >> >> >>> >
>> >>> > >> >> >>> >
>> >>> > >> >> >>> >  I am inclined to agree with
Yuri—if the alternative
>> >>> > >> implementation
>> >>> > >> >> can
>> >>> > >> >> >>> be
>> >>> > >> >> >>> > developed in parallel around
the same protocol, that
>> would
>> >>> seem
>> >>> > >> to be
>> >>> > >> >> >>> the
>> >>> > >> >> >>> > best scenario, but the existing
codebase should be kept
>> >>> because
>> >>> > >> it is
>> >>> > >> >> >>> > (AFAIK) the most functional
implementation of the
>> protocol.
>> >>> > >> >> >>> >
>> >>> > >> >> >>> > Zachary Yaro
>> >>> > >> >> >>> > On Mar 14, 2016 15:05, "Yuri
Z" <vega113@gmail.com
>> >>> > >> <javascript:;>>
>> >>> > >> >> >>> wrote:
>> >>> > >> >> >>> >
>> >>> > >> >> >>> > > I think that more "wavy"
projects are nice, but IMO it
>> >>> > doesn't
>> >>> > >> >> mean we
>> >>> > >> >> >>> > > should abandon Apache
Wave as it is now. I agree
>> there are
>> >>> a
>> >>> > >> lot of
>> >>> > >> >> >>> > issues
>> >>> > >> >> >>> > > with current code, but
I think there's still value as
>> >>> people
>> >>> > can
>> >>> > >> >> see
>> >>> > >> >> >>> what
>> >>> > >> >> >>> > > Wave can potentially be.
>> >>> > >> >> >>> > >
>> >>> > >> >> >>> > > On Sun, Mar 13, 2016 at
8:46 AM Evan Hughes <
>> >>> > >> >> wisebaldone@apache.org
>> >>> > >> >> >>> > <javascript:;>>
>> >>> > >> >> >>> > > wrote:
>> >>> > >> >> >>> > >
>> >>> > >> >> >>> > > > The link for those
who wish to join, Ill also add
>> this
>> >>> link
>> >>> > >> onto
>> >>> > >> >> the
>> >>> > >> >> >>> > new
>> >>> > >> >> >>> > > > website.
>> >>> > >> >> >>> > > >
>> >>> > >> >> >>> > > > https://www.hipchat.com/gsModF8CY
>> >>> > >> >> >>> > > >
>> >>> > >> >> >>> > > > On Sun, 13 Mar 2016
at 12:12 Michael MacFadden <
>> >>> > >> >> >>> > > > michael.macfadden@gmail.com
<javascript:;>>
>> >>> > >> >> >>> > > > wrote:
>> >>> > >> >> >>> > > >
>> >>> > >> >> >>> > > > > Yeah. Chatting
is fine and beneficial. We just
>> need to
>> >>> > make
>> >>> > >> >> sure
>> >>> > >> >> >>> we
>> >>> > >> >> >>> > > > > capture key
decisions and rationale back in the
>> list
>> >>> for
>> >>> > >> all to
>> >>> > >> >> >>> see.
>> >>> > >> >> >>> > > > >
>> >>> > >> >> >>> > > > > ~Michael
>> >>> > >> >> >>> > > > >
>> >>> > >> >> >>> > > > > > On Mar
12, 2016, at 6:07 PM, Evan Hughes <
>> >>> > >> >> >>> wisebaldone@apache.org
>> >>> > >> >> >>> > <javascript:;>>
>> >>> > >> >> >>> > > > wrote:
>> >>> > >> >> >>> > > > > >
>> >>> > >> >> >>> > > > > > It does
not so as Ive seen other projects state
>> this
>> >>> > motto
>> >>> > >> >> "If
>> >>> > >> >> >>> its
>> >>> > >> >> >>> > > not
>> >>> > >> >> >>> > > > on
>> >>> > >> >> >>> > > > > > the mailing
list it didnt happen at all", but
>> allows
>> >>> > for
>> >>> > >> non
>> >>> > >> >> >>> formal
>> >>> > >> >> >>> > > > talk
>> >>> > >> >> >>> > > > > > and back
and forth discussion realtime. The
>> Monthly
>> >>> > >> reports
>> >>> > >> >> >>> that we
>> >>> > >> >> >>> > > > > talked
>> >>> > >> >> >>> > > > > > about back
when we did the hangout session
>> should
>> >>> > >> probably be
>> >>> > >> >> >>> > picked
>> >>> > >> >> >>> > > up
>> >>> > >> >> >>> > > > > > again,
ill add it to the monthly todo's.
>> >>> > >> >> >>> > > > > >
>> >>> > >> >> >>> > > > > > On Sun,
13 Mar 2016 at 11:58 Michael MacFadden <
>> >>> > >> >> >>> > > > > michael.macfadden@gmail.com
<javascript:;>>
>> >>> > >> >> >>> > > > > > wrote:
>> >>> > >> >> >>> > > > > >
>> >>> > >> >> >>> > > > > >> One
follow up question though. Does hip hat
>> store
>> >>> > >> >> conversations
>> >>> > >> >> >>> > in a
>> >>> > >> >> >>> > > > > >> publicly
accessible manner?  If not, we need
>> to make
>> >>> > sure
>> >>> > >> >> key
>> >>> > >> >> >>> > > > decisions
>> >>> > >> >> >>> > > > > >> that
come out of chats are captured and
>> discussed on
>> >>> > the
>> >>> > >> >> >>> mailing
>> >>> > >> >> >>> > > list
>> >>> > >> >> >>> > > > > for
>> >>> > >> >> >>> > > > > >> all
to see.
>> >>> > >> >> >>> > > > > >>
>> >>> > >> >> >>> > > > > >> ~Michael
>> >>> > >> >> >>> > > > > >>
>> >>> > >> >> >>> > > > > >>>
On Mar 12, 2016, at 7:15 AM, Evan Hughes <
>> >>> > >> >> >>> wisebaldone@apache.org
>> >>> > >> >> >>> > <javascript:;>>
>> >>> > >> >> >>> > > > > wrote:
>> >>> > >> >> >>> > > > > >>>
>> >>> > >> >> >>> > > > > >>>
I would get infra to make us a hipchat
>> channel so
>> >>> we
>> >>> > >> have
>> >>> > >> >> some
>> >>> > >> >> >>> > > place
>> >>> > >> >> >>> > > > to
>> >>> > >> >> >>> > > > > >>>
talk casually web interface / irc, but seesm
>> the
>> >>> > jira's
>> >>> > >> >> down.
>> >>> > >> >> >>> > > Looking
>> >>> > >> >> >>> > > > > to
>> >>> > >> >> >>> > > > > >>>
getting this rolling in some way or another
>> by mid
>> >>> > week.
>> >>> > >> >> >>> > > > > >>>
>> >>> > >> >> >>> > > > > >>>
~ Evan
>> >>> > >> >> >>> > > > > >>>
>> >>> > >> >> >>> > > > > >>>>
On Fri, 11 Mar 2016 at 19:48 Evan Hughes <
>> >>> > >> >> >>> > wisebaldone@apache.org <javascript:;>>
>> >>> > >> >> >>> > > > > >> wrote:
>> >>> > >> >> >>> > > > > >>>>
>> >>> > >> >> >>> > > > > >>>>
The client-server protocol would define a
>> protobuf
>> >>> > and
>> >>> > >> >> json
>> >>> > >> >> >>> rest
>> >>> > >> >> >>> > > > > >> services
>> >>> > >> >> >>> > > > > >>>>
so any language that support protocol buffers
>> >>> would
>> >>> > be
>> >>> > >> >> able
>> >>> > >> >> >>> to
>> >>> > >> >> >>> > > make
>> >>> > >> >> >>> > > > a
>> >>> > >> >> >>> > > > > >>>>
client or fallback to the json rest.
>> >>> > >> >> >>> > > > > >>>>
>> >>> > >> >> >>> > > > > >>>>
>> >>> > >> >> >>> > > > > >>>>
On Fri, 11 Mar 2016 at 19:24 Andreas Kotes <
>> >>> > >> >> >>> > > > > >> count-apache.org@flatline.de
<javascript:;>>
>> >>> > >> >> >>> > > > > >>>>
wrote:
>> >>> > >> >> >>> > > > > >>>>
>> >>> > >> >> >>> > > > > >>>>>
FWIW,
>> >>> > >> >> >>> > > > > >>>>>
>> >>> > >> >> >>> > > > > >>>>>
I also consider the idea pretty good and
>> would
>> >>> want
>> >>> > >> >> stronger
>> >>> > >> >> >>> > > > > decoupling
>> >>> > >> >> >>> > > > > >>>>>
of server/client. I'd be interested in a
>> python
>> >>> > client
>> >>> > >> >> >>> > > > > implementation,
>> >>> > >> >> >>> > > > > >>>>>
mostly for CLI and bot integration.
>> >>> > >> >> >>> > > > > >>>>>
>> >>> > >> >> >>> > > > > >>>>>
Not sure whether doing a client-side C
>> >>> > implementation
>> >>> > >> of
>> >>> > >> >> the
>> >>> > >> >> >>> > > > > >>>>>
communication protocol would be best here
>> (so
>> >>> > wrapper
>> >>> > >> for
>> >>> > >> >> >>> more
>> >>> > >> >> >>> > > > > >> languages
>> >>> > >> >> >>> > > > > >>>>>
can follow), or whether native Python would
>> be
>> >>> > >> better. We
>> >>> > >> >> >>> need
>> >>> > >> >> >>> > > > > >> something
>> >>> > >> >> >>> > > > > >>>>>
for non-Java folks in any case, I think.
>> >>> > >> >> >>> > > > > >>>>>
>> >>> > >> >> >>> > > > > >>>>>
Cheers,
>> >>> > >> >> >>> > > > > >>>>>
>> >>> > >> >> >>> > > > > >>>>>
 count
>> >>> > >> >> >>> > > > > >>>>>
>> >>> > >> >> >>> > > > > >>>>>>
On Fri, Mar 11, 2016 at 10:52:34AM +1000,
>> Evan
>> >>> > Hughes
>> >>> > >> >> >>> wrote:
>> >>> > >> >> >>> > > > > >>>>>>
Thankyou all for your feedback and
>> expressions
>> >>> of
>> >>> > >> >> >>> interests,
>> >>> > >> >> >>> > > seems
>> >>> > >> >> >>> > > > > >> like
>> >>> > >> >> >>> > > > > >>>>>
we
>> >>> > >> >> >>> > > > > >>>>>>
may be able to develop some teams together
>> to
>> >>> make
>> >>> > >> this
>> >>> > >> >> a
>> >>> > >> >> >>> > faster
>> >>> > >> >> >>> > > > > >> reality
>> >>> > >> >> >>> > > > > >>>>>>
than just I. Hopefully we can get some more
>> >>> > people to
>> >>> > >> >> >>> express
>> >>> > >> >> >>> > > > > >> interests
>> >>> > >> >> >>> > > > > >>>>>
in
>> >>> > >> >> >>> > > > > >>>>>>
this way forward.
>> >>> > >> >> >>> > > > > >>>>>
>> >>> > >> >> >>> > > > > >>>>>
--
>> >>> > >> >> >>> > > > > >>>>>
Andreas 'count' Kotes
>> >>> > >> >> >>> > > > > >>>>>
Taming computers for humans since 1990.
>> >>> > >> >> >>> > > > > >>>>>
"Don't ask what the world needs. Ask what
>> makes
>> >>> you
>> >>> > >> come
>> >>> > >> >> >>> alive,
>> >>> > >> >> >>> > > and
>> >>> > >> >> >>> > > > > go
>> >>> > >> >> >>> > > > > >> do
>> >>> > >> >> >>> > > > > >>>>>
it.
>> >>> > >> >> >>> > > > > >>>>>
Because what the world needs is people who
>> have
>> >>> > come
>> >>> > >> >> >>> alive." --
>> >>> > >> >> >>> > > > > Howard
>> >>> > >> >> >>> > > > > >>>>>
Thurman
>> >>> > >> >> >>> > > > > >>
>> >>> > >> >> >>> > > > >
>> >>> > >> >> >>> > > >
>> >>> > >> >> >>> > >
>> >>> > >> >> >>> >
>> >>> > >> >> >>> >
>> >>> > >> >> >>>
>> >>> > >> >> >>
>> >>> > >> >> >>
>> >>> > >> >>
>> >>> > >>
>> >>> >
>> >>>
>> >
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message