WebPositive: Implement haiku error messages

[MichaelPeppers]

I know it's not really a priority, but what about implementing NetPositive haiku messages into WebPositive? ​Listed here.

That would bring a more haiku-ish feeling into Haiku, and... they're kinda fun too. =)

Would their usage need some formal written permission from Access Co., btw?

[leavengood]

That is funny that you mention this because I have already been thinking about it and found the page you linked to myself last week. I even started building an HTML page to use for the errors with the haiku error in it. The only thing that I need to do is figure out how to load this error page when an error occurs, with maybe some fallback in case for some reason loading the error page causes errors too. I also think that some of the haiku error messages fit better with different errors and I need to match them up maybe. Though I'm not sure how detailed the errors from WebKit are.

[MichaelPeppers]

Replying to leavengood:

That is funny that you mention this because I have already been thinking about it and found the page you linked to myself last week. I even started building an HTML page to use for the errors with the haiku error in it. The only thing that I need to do is figure out how to load this error page when an error occurs, with maybe some fallback in case for some reason loading the error page causes errors too. I also think that some of the haiku error messages fit better with different errors and I need to match them up maybe. Though I'm not sure how detailed the errors from WebKit are.

That's great, keep up the good work! =)

Anyway, there is another issue that will have to be addressed sooner or later: localization of the error page. Since translating haikus while retaining both the meanings to a comprehensible state and the poetic pattern (5-7-5) sounds like one massive task, very unlikely to be completed in acceptable times, I thought that we could bypass the issue by using the un-localized haiku message followed by a localized "normal" error message below it, while providing a way to disable either of them in the settings.

What do you think about it?

[humdinger]

User taos mentioned on the haiku-i18n-de mailing list that many of those Haiku error codes were apparently from an old ​Salon competition. I think the authors should be credited.

Besides an official error message with error code and possibly a nice icon, the haiku messages should be "localizable" as well, so they can easily be translated or replaced with one in the local language if so desired.

We may also want to give a few hints on possible reasons and fixes for an error where reasonable.

[MichaelPeppers]

Replying to humdinger:

User taos mentioned on the haiku-i18n-de mailing list that many of those Haiku error codes were apparently from an old ​Salon competition. I think the authors should be credited.

+1

Besides an official error message with error code and possibly a nice icon, the haiku messages should be "localizable" as well, so they can easily be translated or replaced with one in the local language if so desired.

As I re-read my previous comment, I see that my concerns about haiku translations were a *tad* overstated. Yes, I totally agree with you. Still, I don't really expect error haikus to be translated, they'll rather be replaced by ones with similar meanings.

[Disreali]

Replying to humdinger:

User taos mentioned on the haiku-i18n-de mailing list that many of those Haiku error codes were apparently from an old ​Salon competition. I think the authors should be credited.

NetPositive already had haiku error msgs before that competition. Most of the messages on that page are Windows related.

NetPositive errors can be seen ​here.

[umccullough]

Has anyone ever asked ACCESS for permission to re-use those NetPositive error messages? I suppose it wouldn't be difficult to fire off a quick message to them to see if they care.

[humdinger]

That's the URL from the original ticket, Disreali. I don't know what came first, Net+ or that competition, at least some of the Net+ Haikus are also on that Salon page.

Anyway, if anyone has a contact at ACCESS, maybe it'd be worth it to also ask them to finally release the BeBook as the basis for our HaikuBook. What's the sense of restricting changes to a document on a 10 year old open API of a dead OS?

[mmadia]

Urias and myself have re-established dialog with ACCESS Co., Ltd. Hopefully in a few more days, there'll be a definitive answer on using NetPositive's error messages within WebPositive.

[mmadia]

From the legal department at ACCESS Co., Ltd.

As for NetPositive's haiku error messages, they are the works 
protected under copyright law. The copyright is owned by ACCESS now.
Like in the case of the BeBook, we are willing to allow the Haiku 
Project to use the error messages under a CC by-nc-nd/3.0.

The attribution can be met by

• displaying "© ACCESS Co., Ltd." as a footer alongside each haiku error message
• WebPositive's about window will mention the CC by-nc-nd/3.0

[bonefish]

IMO we shouldn't bother. We could use fresh haikus provided by the community or drop the idea altogether.

[tangobravo]

I think most of them came from the Salon competition and were used without attribution by Be. Some were slightly modified. Eg the winner of the (Feb 1998) competition was:

Three things are certain:
Death, taxes, and lost data.
Guess which has occurred.
--David Dixon

and this one appears in NetPositive

These three are certain:
Death, taxes, and site not found.
You, victim of one.

I can't find reference to when NetPositive first shipped with Haiku error messages, but I'd bet it was after the competition. Seems more likely someone at Be saw all those entries and modified a few rather than lots of independent people independently stole and slightly modified Net+'s message to submit them to salon.

So I really wouldn't want to claim they were Copyright Access, as it both negates the beautiful simplicity of the poetic representation itself, and also probably falsely attributes the copyright anyway.

I like the idea of Haiku messages, but agree that a fresh set from the community would be preferable (and we can actually make them a bit more appropriate to the actual http_status being reported)

[humdinger]

Right. Having the author mentioned if she's known is fine, mentioning the corporation that just blindly bought it, thrown in with a bunch of other stuff they don't care about, is a different thing altogether.
Once the infrastructure in the code is there (showing different pages with formal error code, texts and icons) there could be a nice little competition.

[luroh]

Moving Web+ enhancements out of R1 milestone.

[sneaky]

Related: #9334

I found a stub/fixme for setting page markup and fleshed it out. I'm not totally happy with it (I think it needs more parameters) but it does work. (Then I found this ticket.) It's pretty easy to add internal protocol schemes, too - too easy, perhaps.

Here's how I think it could go, if I understand all the moving pieces right:

• Frame code LoadURL() method gets a special case for a "chrome:" protocol. We don't have to expose it to Web+ itself because it's just for error messages and the likes.
• chrome: url is handled by looking up the filename and then injecting the content into the page with Frame's method SetPageSource() (maybe with url, content-type, charset params added)
• path lookup for chrome protocol maps to resources "import"ed via rdef
• the UA itself (ie Web+) in src tree has a "resources" folder where it keeps the stuff that'll be imported

I assume you can load from the app's rc-ed stuff from in the lib, since you're looking through a BFile thing?

The benefits of having real files to edit and the custom protocol would be:

• any web guy with any text editor could improve them
• shared assets (icons, stylesheets, scripts?) between pages
• maybe add custom objects/APIs later for JS, like viewing certificates
• relative paths so you could do most of the design without recompiling

The benefits of packing them as resources would be:

• nobody can easily prank you by messing with your error pages
• fewer inodes

Theoretically is it safe to look for resources if they might not be present? Like maybe res.LoadResource() just gives you a dead pointer, you detect that, and fall back on a BAlert?

• ​Making and loading resources
• ​More on making resources
• ​List of Moz chrome URLs, related
• ​More about how Moz guys do it

[pulkomandy]

I'm pretty sure BResource allows appropriate error handling.

However, something to keep in mind is that BWebView will ultimately be used in places other than WebPositive. So, I think the resources should be stored on the library side (either directly in the library, or as files in the data/ directory - I think we do this for the stylesheet for FTP and ​file:// listings already, and should be doing it for the Web Inspector resources as well).

Since these will be stored in the haikudepot package, they are normally read-only, which is a good enough protection against malicious uses. If you have write access there, you can as well replace the web browser executable anyways.

Now the decision to make is wether this should be handled directly by haikuwebkit, and therefore happen in all apps using it, or if it should be a WebPositive-specific feature, in which case haikuwebkit would just raise an error to the application, and the application would decide what to do - embedded HTML error message, alert, embedded native error message (this doesn't have to be HTML, after all), etc.

There is an implementation for loading stuff from Resources in the Haiku port of the NetSurf web browser, which may provide some inspiration as well.