[haiku-commits] Re: haiku: hrev47461 - src/kits/network/libnetapi src/kits/support src/bin headers/private/support headers/private/net
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Fri, 04 Jul 2014 13:22:41 +0200
On 07/03/2014 06:17 PM, Stephan Aßmus wrote:
Am 03.07.2014 17:43, schrieb ingo_weinhold@xxxxxx:
diff --git a/src/kits/network/libnetapi/Url.cpp
b/src/kits/network/libnetapi/Url.cpp
index fb1d499..783e723 100644
--- a/src/kits/network/libnetapi/Url.cpp
+++ b/src/kits/network/libnetapi/Url.cpp
@@ -14,6 +14,9 @@
FWIW, I just moved this code from the private BUrl implementation
without reviewing it. I wouldn't even have touch it at all, if its
header hadn't clashed with that of the public one when using the private
support headers (which is now necessary in places where the new
compression API is used).
I won't touch this code any further. So if anyone feels interested to
clean it up, please go ahead.
[...]
+status_t
+BUrl::OpenWithPreferredApplication(bool onProblemAskUser) const
+{
+ if (!IsValid())
+ return B_BAD_VALUE;
+
+ BString urlString = UrlString();
+ if (urlString.Length() > B_PATH_NAME_LENGTH) {
+ // TODO: BAlert
+ // if (onProblemAskUser)
+ // BAlert ... Too long URL!
onProblemAskUser? That looks like it belongs in another layer.
Indeed. As it seems it isn't even used here.
+BString
+BUrl::_UrlMimeType() const
+{
+ BString mime;
+ mime << "application/x-vnd.Be.URL." << fProtocol;
+
+ return BString(mime);
+}
This looks like you could just return "mime" instead of wrapping it in
another BString.
Yep.
I think the BUrl class should actually be moved to the support kit. Then
BRoster could accept BUrl's.
CU, Ingo
Other related posts:
