Re: [Wikitech-l] SHA-1 hash officially broken

[Strainu]

2017-02-24 21:29 GMT+02:00 Florian Schmidt :
> About the git part: There's an interesting statement from Linus [1] with 
> which I can totally agree (and additionally this one[2]). So probably even 
> this is not a "high priority, do nothing else" task :P

Just FYI, this was confirmed in [3]

>
> [1] http://marc.info/?l=git=148787047422954
> [2] 
> https://public-inbox.org/git/pine.lnx.4.58.0504291221250.18...@ppc970.osdl.org/
[3] https://plus.google.com/+LinusTorvalds/posts/7tp2gYWQugL

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] OOJS-UI: label/data mechanism in "OO.ui.ComboBoxInputWidget"

[Moriel Schottlender]

Hi Robert,

In general, the 'data' property for items inside the GroupElement can be
strings or objects, as they represent some state of your item.
In OO.ui.mixin.GroupElement, the method "getItemFromData" can then return a
specific item based on its data property. If you use an Object for the
data, OOjs-UI will use its OO.getHash() to basically stringify your object,
so it can make sure it retrieves the right one.

The property 'data' actually comes all the way up the hierarchy chain from
"OO.ui.Element" (if you look at that method, the description of that
parameter is the same) -- and at that level, it definintely allows for any
sort of data, be it a string or an object.

However, when dealing with specific cases, like that of the
ComboBoxInputWidget (the terminology of "input widget" usually suggests
something inside a form in OOjs-UI) means that putting the data as an
object doesn't make sense usually. Unless your use case requires something
very different, we usually want ComboBoxInputWidget to have the 'value' =>
'label' pair, so it uses its 'data' property as the 'value' and expects a
string.

As for the second part of your question, I am not 100% sure I understood it
(please correct me if so) but from what I understand, if you set your
OO.ui.MenuOptionWidget items with their data as the value ('red' / 'yellow'
/ 'green' etc) and the label as the mw.msg that the user sees, then it
should work out of the box.

So if you look at the example given in the docs for ComboBoxInputWidget (
https://doc.wikimedia.org/oojs-ui/master/js/#!/api/OO.ui.ComboBoxInputWidget)
you can set your item's data to the color (value) and the label to the word
you want to display, and when the user picks an option, the **label** needs
to show in the ComboBoxInputWidget.

Be aware, though, that if you listen to 'choose' or 'select' event from
this input widget, you get the selected item, so if you're projecting that
choice into some other input, you should ask for the label
(item.getLabel()) and not the data.

I hope that helped...

Moriel



On Fri, Feb 24, 2017 at 12:04 AM, Robert Vogel  wrote:

> Hi everybody!
>
> I'm working on some OOJS-UI components for an extension and I've stumbled
> across something:
>
> The "OO.ui.ComboBoxInputWidget" allows to set an array of
> "OO.ui.MenuOptionWidget" objects in its "menu.items" config field.
> Such an item can have a "label" and a "data" field. The "data" field can
> be of type "object" [1].
>
> Now, if I use a "data" field of type "object" the value of the
> "OO.ui.ComboBoxInputWidget" will be "[Object object]", as it tries to cast
> the "data" value to a string when a user selects an option item.
> So it looks like "OO.ui.ComboBoxInputWidget" allows only "data" of type
> "string" in its options. Is that correct?
>
> That would also mean that there is no "label/data" mechanism of the input
> field itself. If I've got the following options
>
> [
> { label: "Rot", data: "red" },
> { label: "Gelb", data: "yellow" },
> { label: "Grün", data: "green" }
> ]
>
> and the user selects the option with label "Gelb" the input field shows
> "yellow", not "Gelb". Did I miss something? Is it possible to show a
> "label" to the user but retrieve the "data" (object) when calling
> "getValue" on such a field?
>
> [1] https://doc.wikimedia.org/oojs-ui/master/js/#!/api/OO.
> ui.MenuOptionWidget-cfg-data
>
> --
> Robert
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
No trees were harmed in the creation of this post.
But billions of electrons, photons, and electromagnetic waves were terribly
inconvenienced during its transmission!
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Huggle] Fwd: EventStreams launch and RCStream deprecation

[Petr Bena]

Hello,

Thanks for the info, this means that we need to switch from RCStream, is
there any working example code, preferably written in Python or any other
sane terminal friendly language (eg. not html or JS) that is capable of
connecting to this stream and obtaining at least identicat information from
it as we did in case of RCStream?

P.S. I can't help myself but I really have to rant now because I hate how
much MW devs love to deprecate stuff and break compatibilty so often just
for trivial reasons. I am really glad that instead of using RCStream
directly I created that XmlRcs proxy in past, it's gonna save me massive
amount of work, because no, I am not gonna deprecate XmlRcs [1].

P.S. 2.0: Do you really have a date for decommission of a working service
already even though the replacement is still in early-cradle pre-alpha
phase? Is this really the best approach?

1: https://wikitech.wikimedia.org/wiki/XmlRcs

On Thu, 23 Feb 2017 at 22:11, Andrew Otto  wrote:

> Hi everyone!
>
> Wikimedia is releasing a new service: EventStreams
> [1].  This service
> allows us to publish arbitrary streams of JSON event data to the
> public.  (Pt: we’re looking for cool new uses
> [2]
> to put on an upcoming blog post.)
>
>
> Initially, the only stream available will be good ol’ RecentChanges
> .  This event stream
> overlaps functionality already provided by irc.wikimedia.org and RCStream
> .  However, this new
> service has advantages over these (now deprecated) services.
>
>
>1.
>
>We can expose more than just RecentChanges.
>2.
>
>Events are delivered over streaming HTTP (chunked transfer) instead of
>IRC or socket.io.  This requires less client side code and fewer
>special routing cases on the server side.
>3.
>
>Streams can be resumed from the past.  By using EventSource, a
>disconnected client will automatically resume the stream from where it left
>off, as long as it resumes within one week.  In the future, we would like
>to allow users to specify historical timestamps from which they would like
>to begin consuming, if this proves safe and tractable.
>
>
> I did say deprecated!  Okay okay, we may never be able to fully deprecate
> irc.wikimedia.org.  It’s used by too many (probably sentient by now) bots
> out there.  We do plan to obsolete RCStream, and to turn it off in a
> reasonable amount of time.  The deadline iis July 7th, 2017.  All
> services that rely on RCStream should migrate to the HTTP based
> EventStreams service by this date.  We are committed to assisting you in
> this transition, so let us know how we can help.
>
> Unfortunately, unlike RCStream, EventStreams does not have server side
> event filtering (e.g. by wiki) quite yet.  How and if this should be done
> is still under discussion .
>
> The RecentChanges data you are used to remains the same, and is available
> at https://stream.wikimedia.org/v2/stream/recentchange. However, we may
> have something different for you, if you find it useful. We have been
> internally producing new Mediawiki specific events
> 
> [3] for a while now, and could expose these via EventStreams as well.
>
> Take a look at these events, and tell us what you think.  Would you find
> them useful?  How would you like to subscribe to them?  Individually as
> separate streams, or would you like to be able to compose multiple event
> types into a single stream via an API?  These things are all possible.
>
> I asked for a lot of feedback in the above paragraphs.  Let’s try and
> centralize this discussion over on the mediawiki.org EventStreams talk
> page [4].   In summary,
> the questions are:
>
>
>-
>
>What RCStream clients do you maintain, and how can we help you migrate
>to EventStreams?
>
>-
>
>Is server side filtering, by wiki or arbitrary event field, useful to
>you? 
>-
>
>Would you like to consume streams other than RecentChanges?
>  (Currently
>available events are described the event-schemas repository
>
> 
>.)
>
>
>
> Thanks!
> - Andrew Otto
>
> [1] https://wikitech.wikimedia.org/wiki/EventStreams
> [2] https://www.mediawiki.org/wiki/EventStreams/Blog_-_Call_For_Entries
> [3]
> https://github.com/wikimedia/mediawiki-event-schemas/tree/master/jsonschema/mediawiki
> [4] 

Re: [Wikitech-l] Fwd: EventStreams launch and RCStream deprecation

[MZMcBride]

Congratulations on the launch of EventStreams.

Andrew Otto wrote:
>I did say deprecated!  Okay okay, we may never be able to fully deprecate
>irc.wikimedia.org.  It’s used by too many (probably sentient by now) bots
>out there.

I monitor irc.wikimedia.org and it has proven itself to be highly reliable
for many years in production, which is a lot more than can be said for any
of these proposed alternatives. I'm glad to hear that irc.wikimedia.org
will be left alone. If people want to be nasty and call irc.wikimedia.org
deprecated, I suppose that's fine, as long as it remains the functional
and dependable (and completely quirky) API it continues to serve as.

MZMcBride



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l