Note: There are a few cases of duplicates in user autocompletion which are being worked on.

MAR scriptable component, xpmar

NEW
Unassigned

Status

()

Core
XPCOM
--
enhancement
10 years ago
7 years ago

People

(Reporter: cesar, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

10 years ago
Created attachment 273502 [details] [diff] [review]
v0.1 without tests

Currently MAR files are generated using bash and perl scripts. It would be nice if you can create/read mar files without using the command line tools. While this isn't the solution, it is a start to hopefully a small application that xulapp developers can use to generate MAR files of their own.

You can create new mar files, and read existing ones using two different interfaces. Though it is not possible to modify MAR files (you can work around that by getting the Reader's enumerator, and adding it to the Writer).

You are also not able to view the data contained in the MAR file. The rational behind this that MAR files usually hold binary diffs. Binary data usually isn't useful to read, but I can add that feature as well.

You also have to be careful and create and extract MAR files in the same directory. Usually this is the root directory of the application.

It is placed under modules/libmar/xpmar, for https://bugzilla.mozilla.org/show_bug.cgi?id=379633#c13 reason

I wrote some xpcshell unit tests, but need to be cleaned up before I add it here. I just want some initial feedback.
hey, could this and bug 379633 use the same interface perhaps?
(Reporter)

Updated

10 years ago
Status: NEW → ASSIGNED
(Reporter)

Comment 2

10 years ago
(In reply to comment #1)
> hey, could this and bug 379633 use the same interface perhaps?
> 

They could not. From my understanding, MAR does not do any compression. So the interface would not be suitable.
(In reply to comment #2)
> They could not. From my understanding, MAR does not do any compression. So the
> interface would not be suitable.

I don't think that's a reason that they couldn't share the same interface. There is no reason the compression level parameter used in the zipwriter interface couldn't be considered optional (we could even make it optional now I believe), marwriter could ignore it and zipwriter could use a default level if it wasn't present.

I think the main issue is that the interface for zipwriter is somewhat bulky since it supports multiple ways to add data and both synchronous and synchronous modes of operation. This may be more complex than we want to go here. But then again maybe marwriter could just throw unsupported for the methods you don't want to implement, would be a little confusing for users though.
OS: Linux → All
Hardware: PC → All
FYI, I'm not particularly interested in making this part of the default XR, though it would be acceptable to provide it as an addon component that could be shipped with development kits (e.g. XULExplorer). To be useful, we'd have to ship a bzip2 compression algorithm also, which is a fair amount of code.
(Reporter)

Comment 5

10 years ago
(In reply to comment #3)
> I think the main issue is that the interface for zipwriter is somewhat bulky
> since it supports multiple ways to add data and both synchronous and
> synchronous modes of operation. This may be more complex than we want to go
> here. But then again maybe marwriter could just throw unsupported for the
> methods you don't want to implement, would be a little confusing for users
> though.
> 

That too. I'm more worried about (because this is what I am taught. Though there are exceptions to the rule) trying to program a component into an interface that doesn't quite fit it. This can change if you provide a good point, but I'm not convinced yet.

(In reply to comment #4)
> FYI, I'm not particularly interested in making this part of the default XR,
> though it would be acceptable to provide it as an addon component that could be
> shipped with development kits (e.g. XULExplorer). 

That's fair.


> To be useful, we'd have to
> ship a bzip2 compression algorithm also, which is a fair amount of code.
> 

But the bzip2 library is already included in the XR. Could I just not use that (hopefully someone has created a component that uses bzip2)?
Currently the bzip2 library is only linked into the updater.exe binary, and is not available via XPCOM. And I don't want to carry around two copies of it.
(Reporter)

Comment 7

10 years ago
Created attachment 273994 [details] [diff] [review]
Fixed bugs. More comments. Added simple unit tests
Attachment #273502 - Attachment is obsolete: true
This is a mass change. Every comment has "assigned-to-new" in it.

I didn't look through the bugs, so I'm sorry if I change a bug which shouldn't be changed. But I guess these bugs are just bugs that were once assigned and people forgot to change the Status back when unassigning.
Status: ASSIGNED → NEW
You need to log in before you can comment on or make changes to this bug.