Eevans added a comment.
I can be the point of contact for mediawiki/services/kask
<https://gerrit.wikimedia.org/g/mediawiki/services/kask>, and am ready when you
are!
TASK DETAIL
https://phabricator.wikimedia.org/T332953
EMAIL PREFERENCES
https://phabricator.wikimedia.org/se
Eevans removed a project: Cassandra.
TASK DETAIL
https://phabricator.wikimedia.org/T204024
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Eevans
Cc: ItamarWMDE, WMDE-leszek, Lydia_Pintscher, Pintoch, Tpt, Smalyshev, Eevans,
daniel, mobrovac, Jonas
Eevans edited projects, added Core Platform Team Workboards (Clinic Duty Team);
removed Core Platform Team.
TASK DETAIL
https://phabricator.wikimedia.org/T178445
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Eevans
Cc: jcrespo, brennen, Joe
Eevans added a comment.
In T204024#4576751, @daniel wrote:
This use case seems similar to caching parsoid HTML, which is done in RESTbase and backed by Cassandra. It's similar, because it's re-generated upon edit, and accessed from clients upon view, via an API. It's also similar in that losing
Eevans added a comment.
In https://phabricator.wikimedia.org/T116247#1927791, @Ottomata wrote:
> I believe we can close this task, ja? Got a few defined here:
> https://github.com/wikimedia/mediawiki-event-schemas/tree/master/jsonschema/mediawiki
+1
TASK DETAIL
Eevans added a comment.
In https://phabricator.wikimedia.org/T116247#1839888, @Ottomata wrote:
> @gwicke and I discussed the schema/revision in meta issue in IRC today. He
> had an idea that I quite like!
>
> @gwicke suggested that instead of using (schema, revision) to uniquely ID
Eevans added a comment.
In https://phabricator.wikimedia.org/T116247#1749452, @Ottomata wrote:
> Right, but how would you do this in say, Hive? Or in bash?
In bash:
$ sudo apt-get install uuid
$ ID=$(uuid -v 1)
$ grep "content: time" <(uuid -d $ID)
content: time
Eevans added a comment.
In https://phabricator.wikimedia.org/T116247#1748095, @Ottomata wrote:
> > So the producer would store the same time stamp twice? UUID v1 already
> > contains it.
>
>
> Could you provide an example of what this UUID would look like?
>
> A re
Eevans added a comment.
In https://phabricator.wikimedia.org/T114443#1731284, @GWicke wrote:
> In https://phabricator.wikimedia.org/T114443#1730753, @Eevans wrote:
>
> > 1. Already leverages a (really slick) JSON schema registry
> > <https://meta.wikimedia.org/wiki/Category
Eevans added a comment.
In https://phabricator.wikimedia.org/T114443#1726139, @Eevans wrote:
> I've expanded upon @gwicke's prototype a bit, progress here:
> https://github.com/wikimedia/restevent
Actually, after some additional research, I think that we should strongly
consider the ap
Eevans added a comment.
I've expanded upon @gwicke's prototype a bit, progress here:
https://github.com/wikimedia/restevent
TASK DETAIL
https://phabricator.wikimedia.org/T114443
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Ottomata, Eevans
Cc
Eevans added a comment.
> A message queue is not a database, it's a router. ...
Of course, but I drew the analogy because in both cases you have readers and
writers of structured data. That this particular use case is log structured
instead of object relational doesn't change that asp
Eevans added a comment.
In https://phabricator.wikimedia.org/T114443#1701296, @Joe wrote:
> Apart from the concerns on a practical use case which I agree with, I have a
> big doubt about the implementation idea:
>
> I am in general a fan of the paradigm that it's better to beg for
13 matches
Mail list logo
