You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is more a question than an issue. I know there is a HAML forum on Google Groups but I couldn't find any mailing list specific to libsass.
I am looking for ways to pass libsass context structure between threads/processes - in other words to serialize its contents.
Motivation:
I am considering to implement a kind of co-routine interface to libsass. In general it would work like this:
C -> L "compile_file" (context)
C <- L "call custom importer"
L -> C "import this"
C <- L "call custom function"
L -> C "custom function result"
C <- L "compile_file result"
Of course this is not possible with the current API as it is right now, but
maybe it could be available in libsass 4.0
Such an interface could have a couple of advantages:
detaching the parser from the environment like files,
Because we don't offer such interface right now to implement coroutine interface as above I would need to pass context between threads. Some libraries offer public interface to their API structures, so that they can be processed by the client. I've seen some libraries that do not offer structure details, but provide an extra function that just determines structure size (so that the structure can be copied around transparently). Given we have lots of (char *) pointers it wouldn't work probably as-is.
For now I will probably need to serialize data myself and then reconstruct the structure on the L side of my connection as I don't want to depend on libsass internals.
I am thinking of a more low-level C-style wire format (struct, length, char[], length, char[], ...), but providing JSON encapsulation could of course be an advantage.
What would be the best way to implement this? I would like to prepare something that lives outside of libsass right now, but maybe the code could be included in libsass in the future.
The text was updated successfully, but these errors were encountered:
I created a collective ticket to keep track this and other "non-urgent" feature requests, in order to keep the issue tracker a bit more clean for the more 1st aid issues. I would like to encourage everybody interested in this particular feature to add their comments into this closed issue anyway.
Thanks for your understanding and your contribution!
This is more a question than an issue. I know there is a HAML forum on Google Groups but I couldn't find any mailing list specific to
libsass
.I am looking for ways to pass libsass context structure between threads/processes - in other words to serialize its contents.
Motivation:
I am considering to implement a kind of co-routine interface to libsass. In general it would work like this:
Of course this is not possible with the current API as it is right now, but
maybe it could be available in libsass 4.0
Such an interface could have a couple of advantages:
Serialized context implementation:
Because we don't offer such interface right now to implement coroutine interface as above I would need to pass context between threads. Some libraries offer public interface to their API structures, so that they can be processed by the client. I've seen some libraries that do not offer structure details, but provide an extra function that just determines structure size (so that the structure can be copied around transparently). Given we have lots of (char *) pointers it wouldn't work probably as-is.
For now I will probably need to serialize data myself and then reconstruct the structure on the
L
side of my connection as I don't want to depend on libsass internals.I am thinking of a more low-level C-style wire format (struct, length, char[], length, char[], ...), but providing JSON encapsulation could of course be an advantage.
What would be the best way to implement this? I would like to prepare something that lives outside of libsass right now, but maybe the code could be included in libsass in the future.
The text was updated successfully, but these errors were encountered: